C4 
< 

CO 

o 



Q. 
LU 



(19) 



J 



(12) 



Europasdies Patentamt 
European Patent Office 

Office europ^ des brevets (11) EP 0 770 967 A2 

EUROPEAN PATEIfT APPLICATION 



(43) 


Date of publication: 


(51) Int CI- : Guor i7/o0 




02.05.1997 Bulletin 1997A18 




(21) 


Application nunnber: 96202971 .6 




(22) 


Date or tiling. 24.1 0.1 99d 




fQA\ 

(84) 


Liesignatea oomracung oxaies. 


• Btraskaran, Kumar, 


DE PR uB 


c/o Int Octrooibureau B.V. 






5656 AA Eindhoven (NL) 


you) 


Prinritv- 9fi 10 IQQS US 5860 


• Desiraou. Ramld. 


30.10.1995 US 8101 


C/O Int Octrooibureau B.V. 




27.02.1996 US 12327 


5656 AA Eindhoven (NL) 




30.07.1996 US 22787 


• Huang, YIng, 






c/o int Octrooibureau B.V. 


C71) 


Applicant: PHIUPS ELECTRONICS N.V. 


5656 AA Eindhoven (NL) 




5621 BA Eindhoven (NL) 


• KrasinsM, Ray, 






c/o Int Octrooibureau av. 


(72) 


Inventors: 


5656 AA Eindhoven (NL) 


• 


Schmidt, James P., 






c/o int Octrooibureau B.V. 


(74) Representative: Strijiand, Wilfred 




5656 AA Eindhoven (NL) 


INTERNAT10NAAL OCTROOIBUREAU av.. 


• 


BakkalbasI, Omer, 


Prof. Holstlaan 6 




c/o Int Octrooibureau B.V. 


5656 AA Eindhoven (NL) 




5656 AA Eindhoven (NL) 





(54) Decision support system for the management of an agile supply chain 



(57) A dectstonsLfsport system for the management 
of an ^Qe stpply chain that provides an architecture 
including a server side and a client side. The server side 
includes a decision support system database that inter- 
faces with model engine that performs analysis of the 
data to support planning dedstons. The server side 
includes a server maiiager that coordinates requests for 
service and information. The dient side includes ded- 
sion frames tttat present the various view pdnts availa- 
ble in the system to the users. A frame manager 
coordinates the requests from decision support frames 
to access the neected.data and models. The decision 
support franries p>rovide a view into supply chain and 
Integrate analytical models responsive to the view pdnt 
of a business process such as demand management 
The frames indude a supply management frame, a 
demand management frame, a vendor managed 
replenishment frame, a Planning, Sales and Inventory 
planning frame and a d^bution network design frama 
The model engine indudes a component procurement 
poGcy development module, a finished goods distribu- 
tion network design module, an aggregate production 
plarviing module, a finked goods inventory manage- 
ment module, a sales forecasting and planning module, 
a market data analysis rrxxlule, a vendor managed 
replenishment module and various utilities such as 



generic Gnear programming solvers and statistical anal- 
ysis routines. The system also irKludes a demand and 
supply reconciliation process recondling production, 
sales and inventory and recondfing a to(Hiown forecast 
with a bottonvup forecast where an expert based model 
is used for ttie txrttom-up forecast A capacity planning 
process determnes the feasbility of a capacity plan 
responsive to sipply constraints. A vendor managed 
replenishment process plans inventory replenishment 
analysis arxi periods responsive to predicted sales arxJ 
si|)ply constraints. A scenario management process 
^sedated with all frames enables the user to analyze 
different hypothetical scenarios for comparison of busi- 
ness plans. The frame manager indudes a system inte- 
gBtor and a functional integrator. A datat>ase 
management system manages the supply and mainte- 
nance of information needed by the modeling proc- 
esses through the frame manager. A domain 
management process limits data availat)le to said 
frames responsive to a user selection. 
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Description 

BACKGROUND OF THE INVENTION 
5 Field of the InNrention 
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The presertin«ntioo is directed loasystenilw 
of s«v^supply chains lhat span fromapoint<rf<«^ 
to^^aS^van^decision'Lte.sintt^supply^^ 

intom«tion and ei^hHte decisions concOT 
(fiverse set of often oonflcting goals. 

Description Of The Related Art 

^tenytypesofmanu^acturingdataba8emanagementandim,entorycorTfr^ 

tems^Srprocessfn)mtt« narrow vle«pointrttt^ 

to deL«ne when the in^ntory d an Item is projected to 

^dSStion. The in^ control p«K»ss does not genera^^ 
SrtyTrnaterials and machines to safisfy the inventory de^ 
SSiSsT^lability problem txrt does not tate into ac^ 
S^^S^^eH^pSerted Amarketi^ 

asystTLvwllsiwort manager v«th each of these view^ 

that can be made on the supply chain as a whole txrth currently and into the near future. 

SUMMARY OF THE INVEIfTION 

an object of the presert in^«nfion to provide a system that aUows a dedsion naker in a s^^ 
the din^Jir own SU>ective and «xl«stand ft^ 

"° "^isanotherobjectofthepresertinventiontoprovideadistrta^ 

of processing radices and data in maldng diveree different view point deaswns concerning a supph^*^ 
TSrSect of the present inversion to provide a User Interface that projects a v«^ 

FjeriTtfT^ 1 n tSt takes into accourt the view point of the p^ 

"^tt^Xrobjectofthepresentinventiontoprovidequanttativemodelsandana^ 
pJSS^aSSssionsLlefnxnthevariouss^ 

th/elwnra«ied and utaized in across the entire su^^ .^^ . 

ft^ an^Srtthe present invention to provide a scenario management system in wh«h Scenanos can be 
40 saved modified and data transferred between View points or frames. m^.^^*^ 
ttisTSTerc^ectoflhepresertinventiontoallowthe^ 

* ^"1^ SJSS'object of the present invention to provide a system that will reconcile the demand and supply 

"^Sn^^iS^ofthepresent invention toalkMthecreafionofa^ 
fl>Snolanandprovideaprojeclionooncerningwhatisfeasiblein1heproductioasalesandi^^ 

,ora«^^:.2^S^anWcK^ 
■'^^aiTer^'it:^^ 

'^^t^object of the presert invention to provide expert based models that 

''*'?fe'aL'SSS^^~«^ 
"^S^'S^^c^C^nvention^ 

back to users rrflecBng the impact of TocaI'dedsions on global supply chain performance. 

i?e^23e?*jScan be attained by a decision 6^)port system for the mana^en^ of ag.le supply 
chaii^ including a sender side and a dient side. The server side indudes a deoscn sup- 
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port system database that intertaceswrth one a more model engines thai perform analytical processes on the data to 
determine requirements and make projections. The server side includes a s^er manager that coordinates requests 
for service and information. The dient side includes Decision Support Frames that present the various view points avail- 
able In the system to the users. A frame manager that coordinates the requests from Decision Support Frame (view 
5 points) is provided t>y the system to access the rteeded data arvJ models. 

These together with other objects and ad>«ntages which will be sub^^ 
struction and operation as more fully hereinafter descrtoed and daimed. reference being had to the accompanying 
drawings fonrtng a part hereof, wherein like numerals refer to like parts throughout. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 DSS System Architecture in the Context of Manufactiring Supply Chains. 

Figure 2 DSS ^em Architeclure in the Context of Equipment Repair Supply Chains. 

Figure 3 Decision Support Thread. 
IS Figure 4 The Data Spaces in Supply Chain Management 

Fgure 5 Structural Elements in the DSS Database for the Manufacturing Supply Chain. 

Figure 6 Structural Elements in the DSS Database for the Equipment Repair Supply Chain. 

Rgure 7 Specif'icatfon of Decision Support Rama 

Figure 8 Dedsfon Processes in the Manufacturing Supply Chain. 
20 Figure 9 Wgh Level Model of an Equpment Repair Supply Chain and the Dedsfon Processes. 

Figure 10 Process and Data Row Diagram Legend. 

Figure 1 1 Data Space Associations of the Demand Management Frame. 

Figure 12 Process Row of the Demand Management Frama 

Figure 13 Process Row of Order Futfiilment. 
2S Figure 14 Data Row for the Demand Management Frame. 

Figure 15 Data Space Assodations of the Production-Sales-lnventory Planning France. 

Figure 1 6 Process Ftow of the Production-Sales-Inventory Planning Frame. 

Figure 1 7 Data Row for the ProAJction-Sales-lnventory Planning Frama 

Figure 18 Data Space Associations of the Siif)ply Management FranDe. 
30 Figure 19 Process Ftow of the SiJpplyManagcarnent Frame. 

Figure 20 Data Row for the Supply Management FranDa 

Rgure 21 Data Row for the Supply Managenrient Frania 

Figure 22 Data Space Assodations of the Vendor Managed Replenishment Frame. 

Figure 23 Process Row of the Vendor Managed Replenishment Frama 
35 Figure 24 Data Row fcx the Vendor Managed Replenishment Frama 

Figure 25 Data Space Assodations of the DistrSxition Network Design Frama 

Figure 26 Process Row of the Distribution Network Design Rama 

Figure 27 Data Row for the Distribution Network Design Rama 

Figure 28 Seven Modiles and Supply Chain Management 
40 Figure 29 Pareto Analysis for ABC Classifk»ftk>n. 

Figure 30 Scatty Plot for Sales-Vdatility Classification. 

Figure 31 Impact of Sales F^romotion. 

Figure 32 Curve Fitting for Promotion Effect Analysis. 

Figure 33 System Let^ Services, the Seven rtodules and Model Engine Utilities. 
45 Figure 34 Supply Chain Franrie Manager: High Level Architectura 
Figure 35 hfigh Level Architecture of the System Integrator. 

Figure 36 High level object representation of the system integrator portion of the frame manager. 

Rgure 37 High Level Architecture of the Functional Integrator. 

Figure 38 Data Raw Diagram for the Siwly Chan Network Configurator. 
50 Figure 39 Functionality in the Domain Manager. 

Figure 40 Hierarchical Structure of a Scenaria 

Figure 41 Data Row Diagram for the Performance Simulator. 

Figure 42 User-DSS Interaction Process. 

Figure 43 Sample Screen from PSI DSS. 
55 Figure 44 Threadier Application Development Architecture. 

Figure 45 DSS Devefopm^ Platform Environment 

Figure 46 Generic System Architectura 

Figure 47 System Architecture in View of the DSS Prototype. 

Rgure 48 The Logon Diak>g Box. 
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Figure 49 The Opening Saeen of the DSS. 

Figure 50 User Preferences Selection Diatog Box. 

Figure 51 The Select Data Donnain Form. 

Figure 52 Edit Data Domain Dialog box. 
5 Figure 53 Make Product Domain Dialog Box. 

Figure 54 Save Scenario Dialog Box. 

Figure 55 Open Scenario Dialog Bex 

Figure 56 Demand Managenrtent Bottom Up Forecast Saeen. 

Figure 57 Demand Management Top Down Forecast Screen. 
70 Figure 58 Promotion Calendar Main Display. 

Figure 59 The Promotion Selection Wizard. 

Figure 60 The Main PSI Rame Form. 

Figure 61 The Options menu choices on the PSI screen. 

Figure 62 PSI Reconciliation Order Dialog Bex. 
IS Figure 63 The main capacity checking dialog box - The Options tab. 

Figure 64 The Result tab. 

Figure 65 The Production Resource tab. 

Figure 66 The Key Components tab. 

Figure 67 The Bill of Material tatx 
20 Figure 68 The Alternative Components TabL 

Figure 69 The Resource Requirement tab. 

Figure 70 Key Cotrponent Selection Diak)g Box. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

25 

Introduction 

Overview of the DSS Conceptual Architecture 

30 The Decision Support System (DSS) 10 of the present invention (see f igure 1) reOes on quantitative models and 
data analysis routines to provide dedston sufiport Consider tor example the production, sales and Inventory (PSI) plan- 
ning process. An architecture to provide such stpport in accordance with the present inventbn comprises a tt)rary of 
models and routines that are logicaDy linked, regJarly updated and maintained. To support the PSI planning process 
forexanple, one can then enptoy an appropriate siijset of rnodels and routines from the 11^ 

35 lying supply chain abstractkm and provide decision support The present invention assembles the models and routines 
in a fiexble manner, as needed by a d&asm making environment, to enable the DSS 1 0 to provkle custorrized deci- 
sion support with a readily upgradable and scalable library. 

Principal Design Elements 

40 

The architecture of the Dec^bn Support System (DSS) 1 0 for a manufacturing supply chain is shewn in figure 1 
and comprises the princ?>al design elements of : a DSS Database 1 2 with a Database Management System (DBMS) 1 4 
and Supply Chain lnfc)nmatk)n Systems 15, Decision Support Frames 16 which provides the various supply chain view 
points, a User Interiace 18, a Model Engine 20 including various Model Engpne UtaitieG (processes) 22 and a Supply 
45 Chain Frame Manager 24. The architecture of the DSS 1 0 in the context of an equipment repair supply chain is illusr 
trated in figure 2. 

SaGent Features 

50 The DSS architecture comprises two basic mode drvisbns: the CTient Mode 30 and the Server Mode 32. These 
modes can be classified with respect to an implementation of the DSS 1 0 in a sif)ply chain. Rom a design standpoint 
the Client Mode 30 is the portion of the DSS architecture that is specific and therefore customizable to provide dectskwi 
support for any particular deciskyi process and decision maker. The Sender Mode 32, on the other hand, is the kernel 
of the DSS architecture that remains largely the same across different applications of the DSS 1 0 within a given si^ly 

55 chain. Hence, lor a given inplementation of the cfient-server DSS architecture in a supply chain, there win be one 
Server Mode 32 and a nurTi>er of Client Modes to provide support for the decision processes. 

As shown in figures 1 and 2 the Cfient Mode 30 comprises the User Interlace 18. the Decision Support Franks 16, 
and the client version of ttie Supply Chain Frame Manager 24. The Server Mode 32 comprises the Supply Chain Frame 
Manager 24, the system level servfoes, the Model Engine 20, and the DSS Database 12. The Supply Chain Frame 
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Manager 24, as a partidparTt in both modes, serves to tie the Client and the Server Modes of the architecture together. 

The dient-sen/er architecture makes the overaD design txjth extensil)le (new functionality can be added by custom- 
izing a frame in the Cfient Mode 30) and scalable (new models and routines can be added to the Model Engine 20 in 
the Server Mode 32). MditionaWy this design is networkaWe; one can visualize the Server Mode 32 of the DSS 10 
hosted ly a server wortetalron in a client-server network whHe a number of Cfient Modes 30 of DSS 1 0 are hosted in 
the cfient conpulers. The layered design off the architecture, in tenns of how the princ?)al design elements of the DSS 
1 0 are po6itk)ned within the architecture, provides a more resilient and stable backbone for decision support The high 
lafel design architecture is independert of any computing and networking platfonn and h« 
environments. 

The structure maintains the design of the horizontal layers lor its key system elements while its functionality is more 
aligned vertically. The overall DSS 10 interfaces with the Supply Chain Infomrialion Systems 15 through the data 
exchanges between these systems and the DSS Database 12. The DSS 10 hasa User Interface 18 to interact with end 
users through interactive and visual data exchanga Thus, the main body of the DSS 1 0 includes the following horizorttal 
layers: Lteer Interface 18; Decision Support Rames 16; Supply Chain Frame Manager 24 (Qlent and Server); Modd 
Engine 20; and DSS Database 12 . 

As prevkMJSly mentk>ned. the above layers of the DSS 10 can be partitioned into cfient and Server Modes. The sys- 
tem layers within the Client Mode 30 serve an interpretive role between the system data and analylk; processing sup- 
port and the specific end user's decision SLf)port needs. Those layers under the S^ver Mode 32 contain system 
functionalities common to a diversity of users and dedsicn support problems, and usually require more dedicated, 
h^er performance system processing capabilities. 

To capture and process a user's dedsbn support request the DSS 10 will invoke a vertical decision support thread 
40 ^>ing through visual objects of a User Interface 18. decision togic and what-iff scenario manager in a Decision Sup- 
port Frame, Supply Chain Frame Managers, models or analysis routines in the Model Engine 20 and appropriate data 
elements in the DSS Database 1 2. An example of a dedsfon support thread 40 \s shown by the bi<llrectional arrows in 
figure 3. 

Relevant Si4)pty Chains 

The detailed dfecussion and speciffrcatk)ns for the Decision Support Frames 16 provided in this document are 
generic in nature so that the functionality and system features in the resulting DSS 10 can cover dedston environments 
for a cfiversity of supply chains. The system specif k^atkxis and descriptk)ns in this document address the two distinctive 
supply chains prevkM^ mentioned: I. Manufacturing: Rnished goods are produced from raw materials, components, 
and sut>asserTt}lies using resources (ag., humans and machines) distributed to the demand points, and consumed by 
the end users. Material flow can be characterized as linear. II. Equipn>ent Repair: F=yied items are sent to the repair 
facflilies, repaired using resources (ag., humans and test equpment), and restored to usable condition. Material ftaw 
can t>e characterized as reentrant 

Even though a typical manufacturing environment may perform a limited anmnt of repair operations, such as 
machine maintenance or product sendee, its resources are predominantly decficated to material procurement, finished 
goods productk>n and cfetribution. In this view, the extinguishing characteristic between the manufacturing and repair 
environments is the degree to which the environmenl focuses on the productkm off new goods versus the repair of old 
ones. Conpared to the manufacturing supply chain, the equipment repair supply cffiain has complex reentrant fkiws, 
while the manufacturing is characterized l>y the linear material f taws from material procurement to final consumption. 

DSS Database 

Overview 

The DSS Datat)ase 12 is internal to the DSS 1 0 inrplementalion. The main objective off the DSS Datebase 12 is to 
support the executtan of the decision sufiport ffuncttonality off the DSS 1 0. It contains the synthesized data drawn from 
a variety off external sipply chain information sources and Supply Chain Information Systems 15. It may also nraintain 
a setoff data unique to the DSS 10 but not available in any existing Supply Chain Information Systen« 15. An example 
off such unique data is the data derived through the analysis off synthesized data. The DSS Database 12 can t>e inter- 
faced to the Supply Chain Infformation Systems 1 5 to retrieve the required data and provide updated data as needed. 

The Datat>ase Management System 1 4 (DBMS) communicates with the Model Engine 20 to provkie the input data, 
and lipdate the database 12 based on the output of the Model Engine 20. In general the DBMS 14 does not duplicate 
the transactk)n-t)ased functk)nality that is typwcally featured in the Supply Cffiain Information Systems 1 5, unless it is crit- 
ical for decision support needs. 
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Data Representation Scheme 

Choosing an appropriate data representation is irnportarrt to ensure data consistency, and reconfigurabilrly. 
5 Stnx;tural Data Representation 

A stmctural data representation of the data in various data spaces 50. 52 and 54 (see figure 4) is used to mode! 
the elements of the stppty chain that are relatively static. Specifying these data elements typtcafly specffies the infra- 
structure of the supply chain. At the highest level of abstraction, four principal nodes (see figures 5 and 6) in the si^ly 
10 chain 58 are identified: 

Demand node 59: The customer demands are charactwized atthis node. 

Inventory Node 60: Inventories of key conponents or finished goods are identified to be at these inventory nodes. 
Production Node 61 : Production resources (or finished goods supply) are located at production nodes. 
IS Conponent Supply Node 62: The supply points of toy conponents are characterized at the component sipply 
nodes. These structural (fela elemente are spatially dislrftxited along the supply chain 58 (see figure 5). The rela- 
tionship behween these nodes is preferably nxxJeled in the form of a netvir^ 

lection of Brte that connect the principal nodes. A link establishes a togcal relationship between two nodes, whteh 
may have several altrftxjtes siK^h as distance between the two nodes, transportalton lead time, etc. 

20 

In greater detafl, the Structural data elements and their relationship to the princ^ 

conponents 63 are suppfied by componertsuppBers 64 tied to spedffccom^^ nodes 62. Production 
resources 65 produce the various products 66. The production resources can be aggregated into production resource 
groups 67, and are k)cated at production nodes 61 . Products 66 are the end items that are produced and, based on 
25 their various attributes, can be grouped into vark)us product groips 67. These ^ 
locations identified with inventory nodes 60 and inventory headers 68. Custo^^ 

into customer groups 70 and demand various products. Customers 69 are kxMted at the demand nodes 59. Mari«te 
71 are defined for a cross-section of customers and products. 

A similar structure can be provMed lor the repair chain as illiKtrated in figure 6. 
30 Such a data representation in the form of a nelworit of nodes and the ability to group the various constituent ele- 
ments, provide the flexibility to specify and reconfigure a variety of supply chains. 

Process Data Representation 

35 In adcfition to the structural elernents, the data associated with the various proc^^ 
be represented. TT^ process data elements are relatively dynamk: with respect to tim^ 
transform data related to the various stnictural elernente. To characterize the process 

tional data structures. 
40 Data Space 

A data space is a fundamental dornain to characterize basfc data elements associated ^ 
agement demand, supply and inventory data The data spaces 50. 52 and 54 tie the stniclua^ 
tt has three principal cfimensfons:Producl/Conrponent.rirne; and N^ element. As the nodwelated 

45 Structural etemert can be a custonwr, an inventory tocation, or a production resourca The dat^ 
be at any resdution Or^ terms of level of aggregation) atong the three dimensions and can be 
or valua Thus, each point in the data space char^erizes the resolution of the product (or component), the time and 
the node-related structural element. For exairple. when descrfoing the aggregate procfoction plan data, a product can 
be at the resolution of product time at a resolution of week, and the node-related structural element (Production 

50 resource In this case) at a resolution of production resource group. On the other hand, in describing bottom-up fore- 
caste, a product can be at the resolution of product time at a resolution of month, and node related structural element 

at the resolution of customer. 

We identify three principal data spaces associated with supply chain rnanagemert:Dern^ Inven- 
tory Data Sp^ 52; and Supply Data Space 54. These data spaces are pictorially represented in figure 4 and are 
55 explained next 

Demand Data Space 50: This data space 50 has three dimensions: Customer; Product and Time. Customer can 
be at a resolution of customer or customer group or demand node. Product can be at ttie resolution of product or prod- 
uct groip. Time can be at a resolution of day, we^ bi-week, month, bi-month. quarter or year. 

Supply Data Space 52: This data space 52 has the following three dimensions: Production Resource; Prod- 
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uct/CoTTporent; and Tima ProAjction resource can be at a resolution of production resource, production resource 

groups or proAK;tion node. Product/Conrponent can t)e at 1^ 

can be at a resolulkw of day, weeK bi-week, rnonth. bi-monm, qu^ 

Inventory Data Space 54: This data space M has ttie followng three dii^ 
tion; Product/CoiiponentandTlma Inventory location can be at a resolution of slock location or inventory ^ Prod- 
uct/Conponent can be at the resolution of component, product or product group. Time can be at a resolution of day, 
week, bi^veek, month, bi-month, quarter or year. 

A decision process relates or transforms data either within a data space or between data spaces. For exarrple, 
ag^egate production planning transfbnns data from the supply space to inventory space and vice versa. We wfll 
env)loy this data space representation to specify the various decision processes in supply chain management 

The DSS Database 1 2 comprises structural information pnfbrmation related to relatively static information such as 
product groips, market groups, supply chain nelwork. e*c.), and process information (dynamic intormation related to 
demand, production plan, ete.). Figure 5. previously (fiscussed. graphically represents the structural data tables for the 
manufacturing supply chain. 

Similarty. the DSS Database 1 2 for the eqiapment repair supply chain (see figure 6) comprises structural informa- 
tion fmfonnation related to relatively stetic information such as equipment, repair resources, supply chain network, ete.), 
and process information (dyr^c infomwtion related to usage, requirements, repair plan. ete.). Again, the stmclural 
elements are f lexft)ly collected into different grotps to aDow users to analyze data at various resolutions. For exarrple, 
equipment of the same age can be grouped together to analyze the effect of age on repair requirements. Figure 6 
graphically represents the structural data tables for the equipment repair supply chain. 

The process data in the DSS Database 12 are contained in two ctosely related table type data structures (see 
below): (I) header file that specifies the resolutions and values on the relevant dimensions of product, customer, time, 
resource, and item, (ii) corresponding data file whrch contains the actual data at the resolutions and values specified in 
the header. The process data are preferably stored in these two tables (Table 2, Table 3), rather tiian one consofidatol 
table (Table 1). to avoid redundancy and updating anomalies. A toss-less join of the header and the data tables will 
result in the consolidated table (Table 1). The following exarrple demonstrates this point 
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Table 1 

A single consolidated table with redundancy (not in normal 
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Table 2 

Header table that provides the series information 
and the various identifiers 



Header ID 


Time 
Period 


Ouantitv 


1 


8/1/96 


10 


2 


6/1/96 


20 


2 


7/1/96 


30 


2 


8/1/96 


75 


2 


9/1/96 


50 


3 


6/1/96 


12 


3 


7/1/96 


40 


3 


8/1/96 


57 


4 


9/1/96 


50 


4 


10/1/96 


2 


4 


7/1/96 


3 


5 


1/1/96 


40 


5 


2/1/96 


2 


6 


5/1/96 


74 


7 


3/1/96 


3 


7 


6/1/96 


565 


7 


4/1/96 


500 



Table 3 

Data table that contains references to the header table 
and the time series data 



Data tables 

The data tables in the DSS Datab^ 12 are preferably specifted as follows: Name of the table; Brief description of 
the data contained in the table; Identifier for the data fields; Type of the data field; and Brief description of the data fields 
(this indudes the choice of values for the data in this field, if applicable). 

TTie specifications of the data tables for the manufacturing and equpnr^ repair supply chains can be found in 
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Appencfices A and B, respecthfety. The list of the pref OT 

Aggregate Production Plan Data; Aggregate Production Plan Header; Budget Data; Budget Header; Calendar; Com- 
ponent; Corrponent Accommodation Matrix; Component Requirement Data; Component Requirement Header; Com- 
ponent Suppfier; Conponent Supply Contract; Component Supply hiode; CPRD TMe\ Customer; Customer Grotp; 

5 Customer G^oip; Defirition; Customer Orders; DataRekJ Delrition; Demand History Data; Demand History Header; 
Demand Node; Demand Orientation Data; Demand Orientation Header; Domain; Domain Definition; Feature Choices; 
Forecast Data; Forecast Header; Freight Rate; Inventory Data; Inventory Header; Inventory Node; Inventory Parame- 
ters; Mart^ Data; Market Header; Material Delivery Schedule Data; Material Delivery Schedide Header; Planning 
BOM; POS Data; POS Header; Product; Product Features; Product Grotp; Product Grotp Definition; Production 

10 Accommodation Matrix; Production Capacity Data; Production Capacity Header; Production Matrix; Production Node; 
Production Requirements Data; Production ReqJrements Header; Promotion Data; Promotion Header; Resource; 
Resource G^otp: Resource G^oup Definition: Sales Requirements Data; Sales Requirements Header; Scenario; Sce- 
nario Date; Compattoflity; Scenario Definition; S^ Matrix; Suppty Chain Networi^; SuppJy Order Data; Supply Order 
Header; Terrporary Product List; VMR Contract VMR Date; and VMR Header 

15 

Core Reports 

The present invention pr^eratsly provides core reports that support txjsiness decision processes tiycharac^ 
the link t>etween the various date elements and processes. They synthesize the date and informatkxi used in the ded- 
20 sion making processes. Associated with each key business process, we will demonstrate the date f bw relationships 
that are used to construct the various forms and reports. Some of the preferred forms and reports relevant to the DSS 
10 are: Sales Plan; Customer-Demand hfistory; Productkxi-Sales-lnventory Plan; Master Productkm Plan; Production 
Capacity Plan; Replenfehment Schedule; Customer-DC Assi^ment; and Supply-DC Assignment 

25 Decision Support Frames 

Overview 

Rom a user perspective, a Frame 1 6 is an inte^ated decision support environment based on an abstraction of the 
30 supply chain designed to address a set of related decision problems within a decision process. A Frame 1 6 is therefore 
defined based on tfie vantage point or view point of the users atong a supply chain. This implies that a frame exists if 
and only if there are users with spedfk: needs in the suppty chain. 

From a system perspective, a Frame 16 is a mechanism that unifies the user diak3g and dsplay, the models and 
analysis routines, and date in a rnarmer that is oorisistem to support the undert^^ 
35 A surnrnary of the frarne concept from both a user and a system perspective is shown In TaU 
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46 



50 
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System Perspective 


An environment to address 
a collection o£ related 
decision problems. 


It is a subsystem that 
processes user requests in 
the form of Scenarios. 


Always associated with a 
decision maker or a group 
or decxsion maxers . rrame 
exists if and only if 
there are decision makers. 


It consists ot a 
consistent set of process 


Has a unique perspective 
of the underlying supply 
chain baised on the 
T"»HnrtTiHibiT itv of the 
decision makers associated 
with the frame. 


It xinifies the User 
Interface, Model Engine, 
and DSS Database elements 
that are specific to a 
decision making process. 


Enhances the coordination 
of decision making 
implicit in the definition 
of the frame. Enforced 
through orgcmizational 
accountability and 
responsibilities . 


A convenient client-server 
architectiire that enables 
the extension of the DSS 
functionality. 



Table 4 

Frame Concept: User's and System Perspective 



30 

Frame Architecture 

The high level design of a Decision Support Frame 16 and its interaction with the User Interface 18, the Stpply 
35 Chain Frame Manager 24. the Model Engine 20, and the Datat>ase 12 is niustrated in figure 7. A Frame ^^^2 is the 
abstraction of the supply chain from a user's point of view. It essentially contains as its design elements a user dialog 
72andusercfisplay74andadecisicn logic 76. The user dalog 73 and the display 74 contain the form and style of the 
User Interface 18. The decision logic 76 permits the assembly of models and ana^ routines and the assocated data 
toaddressthesetcf related decision probierns. Fa exannple, in the case of the PSI Planning Frame 160, the user cfia- 
40 log 72 and display 74 are customized to ttie specific needs of the PSI planning process, which further determines the 
design of the User Interface 18 associated with the PSI Planning Frame 1 60. Users will interact with the PSI Planning 
Frame 1 60 through the User Interface 1 8 t)y formulating Scenarios 78. Based upon the Scenarios 78. the decision logic 
76 in the PSI frarrie may assemMrnodels and routines from the Model Engine 20 along with the associated data. The 
decision lo^ 76 m a franrte iriteracts with the Supply Chain Frame 
45 Supply Chain Frame Manager 24 then provides the perfonriance feedback t^ 

Decision Processes in the Manufacturing Sufjply Chain 

The decision processes in the manufacturing supply chain are depicted in figure 8. We tiave identified five decision 
50 processes closely associated with the key decision makers and potential users in a supply chain: Overall Supply Chain 
Management 80. Demand Management 81, PSI (Production-Sales-lnventor^ Planning 82, Supply ManagOTent 83. 
and Vendor Managed Replenishment (VMR) 84. 

Overall Supply Chain Management 

55 

A supply-chairvwide view and the necessary Marwgement 80 is recogiized by all levels of the management as 
b&ng vital to mana^ng the business. However, dec^ion mak^ at diff^ent levels and points along the supply cf^ 
are primarily motivated by tfieir individual roles and responsibiRties. The broader a decision maker's responsftMlilies. the 
more likely the decisum maker is interested in employing dedskxi support capabilities that target the entire siwly 
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chain. The user requirements discussed belcw for decision support are posed from a supply-chain^wide perspective. 
Given the uncertainty in the mediuno- to long^erm sales forecasts, determine whether or not the ertterprise should 
expand, maintain or reduce its production capacity and/or stocks for the critical components. When changes in Iwsi- 
ness conditions irrfwct one part d the supply chain, assess the potential irr^^ 

GSven different future txsiness scenarios, determine their financial consequences across the supply chain. For the , 
enterprise's sigjply chain which includes m^ retailers, determine the appropriate cfivision of responsa)flities for all 
partners in the supply chain. Dofelop and implenrtent performance incentives that will enhance and encourage supply- 
chain-wide thinking and dedsfon making in the enterprise. 

Demand Management 

Demand Management 81 is the process by wfnch the customers' requirements are characterized with the specifi- 
cation of prevaiBng uncertainty. The process involves the development and maintenance of mecfiunrv-tenm customer 
(bottom-ip) forecasts. These faecasts are inrliaify developed in periocfic joint meetings or communications between the 
decision makers of the enterprise and the customers. S*iisequently, these forecasts are input into the enterprise's sup- 
ply management system to obtain product aitocatfon approval (ptece-keeping order). As the actual purchase orders 
arrive, the enterprise attempts to fulffll the requrements to their customers' satisfactfon. We have identified the user 
requirements discuss betow for decision support for this process. Synthesize information from different sources in order 
to manage the demand requirements effectively, &g., accessing pointKrf-sales (POS) data and conparing these with 
shipmert history and cuslonrier forecasts. For key custonrers, devetop c^ 

torical shipment and seO*rough data. Link POS data, where available, to the historical pronxrtfon information to ana- 
lyze the real inpacl of promotion activities on demand, as opposed to relying on the estimates provides by the retailers. 

PSI Planning 

PSI Planning 82 is a process to determine a set of fe^We sales, production and inventory requirenr»nts for 
mecfium to tong-term capacity and resource planning for the logistics operations. At the beginning of each fiscal year, 
an initial PSI plan can be devetoped based on the long-term top<fown sales forecast and budget plans. The planning 
process then becomes a continuous effort to update the existing PSI plan to accomnxxlate the changes in the require- 
ments before and after a series of monthly PSI planning meetings whose participants include decision makers repre- 
senting all key functional areas at the enterprise The meetings integrate the inputs from various sources, resolve 
possiljleconfricls. and balance the concerns of differertt functions in order to recondle,devetop and approve a new set 
of feasible sales, production and inventory reqiirements. The process represents a focal point for the entire togistics 
planning process, and interacts and coordinates witti all rnajordedskxi nraWng processes. We have Wentified the user 
recpjirements discussed betow for deciskxi support for this process. Generate mari«t trend forecasts by product cate- 
gories for the enterprise as well as the entire industry. Such forecasts wiD be based on avaBable shipment history, indus- 
try survey data and influential economic incficalors. Generate forecasts for new products and managing product 
transitions. l^dWate devetoprnert of nftedun>4erm top-<town and b^ 

devetoprnert of production plans and the associated requirernerits plans for Evaluate the effects 

and understand the implications of specrffo changes in the sales or production plans. Confltet resolution nrtechanisms 
are needed to adapt and maintain these plans. Identify those products that wouM be affected by the shortage of certain 
critical corrvnnents; one possfole approach is to use an implosion tool on the bin of materials. Provide a formal mech- 
aritsm to d^errrirw and reaciust appropriate inventory levels for various 

Supply Management 

Siwly Management 83 is a process to determine the production (supply) plan to meet the production (supply) 
requirements generated by the PSI Planning process. The process involves corrponent procurement and factory pro- 
duction p»ar»«ng based on the PSI plans and their changes. At the beginning of the process, the production line capac- 
ities are aeated based on tong-term product plans, i.a. planned new product release. The process continuously 
updates the production (supply plan based on changes In the production (supply) requirements generated in the PSI 
process. We have identffied the user requirements discussed bek3w for decision support for this process. Determine the 
feasfoaity and the econorrtc viability of changes in the production (supply) plan, when changes occur in the PSI plans. 
This reqiirement is motivated by trade-offs between the PSI process and the production (supply) planrting process. 
Evaluate posstole options to accommodate changes in the production requirements, after the One structure and capac- 
ity are determined. Such an analysis is a requirement of the factory planner. Devefop an aggregate level representation 
of the production line capacities so as to h^ the planners in developing aggregate production plans or checking pro- 
duction capacity. Develop a rough-cut analysis c^p)ability to assist the planners in translating the production require- 
ments into critical component requirements. i.e., conponents featured in the planning t)ill of materials. 
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Vendor Managed Replenishment CVMR) 

VMR 84 is a process in which the sillier takes on the responsibility of managing the inventory at the customer 
srte tor the pnxlucis rt supplies. This process operates on poirtK3f-«ales d 
vided by the custorners. N^R inwohres formulating the O)^^ 

as well as deternining the operating parameters such as shipment quantities and replenishment frequencies. We have 
identffied the user recprements <fiscussed below tor decision support for this process. Develop a strategic analysis tool 
to delennine mutually beneficial VMR contracts based on financial and logistics factors. Develop the replenishment 
plan based on factors such as seD-through and inventory information provided by the retailer, promotion activities, prod- 
uct availabiGty and transportation cost trade-offs. 

Decision Processes in the Equpment Repair Supply Chain 

Overview of the ec^pment repair supply chain 

The equipment ref^ aipply chain 90, as depicted in figure 9. includes the operating location 92, i.e., the point-of- 
use. the repair shop 94, and the component suppliers 96. In an equpment repair supply chain, the demand (or the 
"requirements") are generated by equpment failures. When equipment fails, the failed module is replaced from the 
slock at the operating location 92. and the fafled module is eventually sent to the repair shop 94 lor repair. A module is 
made up of repair itemswWchintumaremadeupof components. At the repair shop 94, the repair is carried out by the 
repair resources (people and machinery). Duing the repair process at the repair shop 94, certain repair items and com- 
ponents are replaced. Based on the repair needs, repair rterns and components wSI be bid w 
^ by the repair shops. 

Equipment Operating Location 92: At the equipment opwating location 92, personnel may replace only certain 
repair items of the module, instead of the whole module These replacement repair items may come from the stock or 
from other failed modules. This process encourages consolidation of fafled modules at the operating focation. In the 
consolidation process, the broken repair item of a broken rnodule is replaced by a good repair ite^ 
module. This process may be motivated by Vie stnjcture of the repair cost function and the need for quick repair. In 
some cases, due to the fixed costs of sencfiig individual modules to the repair shop. modJes are batched to a certain 
level, before they are sent to the repair shop for a corrplex overhaul. 

Repair Shop 94: The repair shop 94 is responstote for all the major repairs. The type off repair to perform is driven 
by the level of good modules at the repair focation. When good modules are sent from the repair shop to the operating 
location, the stock level may drop below the targrt level, thus tri^ering a repair request to bring the slock level up to 
the target level. This target level is detennined with the objective of maximizing the equipment avaitebiTity and nnnimiz- 
ing the repair costs. Component and capacity requirements corresponcfing to a repair request should be feasible with 
respect to component avaflabiety and resource capacity lev 

Paraflel with the manufacturing supply chain: 

We recognize the operational cfifferences between manufacturing and eqi4)ment repair supply chains. However, 
the equ?)mert repair supply cf^n tes dear parallefism with the manufa 

respond to products and components correspond to materials. Equipment operating focations are similar to retailers 
and equipment is ike customers. The repair shop is analogous to a production fadfity. As modides are made up of 
repair items, modiies correspond to product groups. The repair requirements management process fe anatogous to 
demand rnanagemerit, and repair supply managernent to supply management Similar to the PSI process, there exists 
a reconcfliation process in the equipment repair supply chain to ensure balance between requirements and si^hr- 

Application to a national defense appGcation 

For a national defense application, the following nomenclature is used. The equipment focated at various operating 
locations are the aircraft operating at the various bases. The modules correspond to the Une Replaceable Units, or 
LRUs and the repair items correspond to Shop Replaceable Units (SRUs). The failure of an LRU, caused by the failure 
of its SRU, renders the aircraft wiavalable. The fuiction of the base is to provkie immediate support to the aircraft 
locatedatthatbase, with the objective of maximizing avaiTabflity of airc^ For that purpose, bases stock good urtits of 
replaceable items, caned serviceaWes, so as to be able to replace a failed LRU of an aircraft immediately. A base, usu- 
ally, is not invoh«J in major repairs. Instead, it implements a consolidation policy (repfadng the defective, SRU of a 
newly failed LRU with a good SRU of an already defective LRU), wrtch gives the base the abflity to manage the repair 
requirements of the depot Managing the repair requirements refers to deciding when and which defective items the 
base will swl to the depot for repair with the objective off maximizing the avaifability off aircraft focated at the base and 
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total cost of repair (which irK:lude5 a f ixed cost connponent). 

A depot is responstole for all the major repairs. The type of repair to perform is driven by the la^el of good repairable 
items at the depot VVheri good repairable items are serrt from the depot to the base, the stoc^ 
target level, thus triggering a repair request to bring the stock level up to the target level. This target level, also called 
the Consdidaled Serviceable Inventory (CSI) level, is determined by the depot with the objective of maximizing its serv- 
ice level and rnrdrrazing its repair costs. Component and capacity requirements corresporKfing to a repair request 
should be feasUe with respect to corrponem availabifity and resource capacffy 

Table 5 below presents the analogy and nomenclature between the equipment repair supply chain, and the manu- 
facturing supply chain with examples from defense and commercial environments. 



Equipment 
Repair Supply 
Chain 


Example 
Defense 
Equipment 
Repair Supply 
Chain 


Example 
Commercial 
Equipment 
Repair Supply 
Chain 


Parallel with 
Mcunufacturing 
Supply Chain 


Equipment 


Aircraft 


MRI Machine 


Customers 


Module 


LRU 


Cabinet 


Product Group 


Repair Item 


LRU / SRU 


Circuit 
Boaurds 


Product 


Component 


Bit and piece 
part 


IC 


Component 



Table 5 

Analogy and nomenclature between equipment 
repair aund manufacturing supply chains 



Decision Processes in the Equipment Repair Sif)pty Chain 

The supply chain comprises (see figure 9) the following three decision processes: Requirements ^to1agement 
Process 98; Requirements-Supply Reconcfliation Planning Process 100; and Supply Management Process 102. 

Requirements htenagement Process 

The ReqMrements Management Process 98 corKentrates on the activities associated with requirements estima- 
tion. The ofajective of this process is to estimate future repair requirements generated tsy equipment failures. Equipment 
f\as several repairable parts arvJ equ9>ment failures are caused by feilures of the repaiFak)le parts. Hence estimating 
future requirements refers to the process of estimating failures of the equpment and of the repairable parts that caused 
the failures. This is done to estimate repair time requirements (determined in Requirenrtents-Supply RecondGation 
Planning Process) and equipment ava3at>0ity at equipment locations, both of wfuch deperxJ on the part that has failed. 

Requirements can k>e analyzed in two levels: Lower level requirements, called the Raw Requirements, correspond 
to all repair requirements of tfie equpment arxi upper level requirements, caOed the Consolidated Requirements, cor- 
respond to requirements requested from the repair shop^ since equpment locations may prefer accumulating their 
repair requirements and serxfing them to the repair shop according to certain rules instead of sencfing them as they 
occu, or may prefer carrying out minor repairs within the location, with the aim of reducing the fixed and variat)le costs 
of repair. In the manufocturing analogy, raw requirements would oorresporvJ to Point of Sales (POS) data and consoli- 
dated reqiirements to retailer order data from the production facility. 

Two cBfferent estimation approaches tfiat have t>een used in this process to estimate consolidated requirements 
are: Bottom-tp Estimation Approach; and Top^lown Estimation Approach. 

The txjttonrHp estimation approach estimates the raw rec^irements first and then generates the consolidated 
rec^irements from raw requirement estimates. In order to estimate raw requirements, relationships are determined 
t)etween failure rates and activity schedules of the equiprnent Fk)re9ample, the time to fa^ 

a function of the number of hours it has operated and its maintenance schedul a Odcb the relatk>nships between failure 
rates and activities are estat)lished regression or time series models, future failure rates can be estimated based on 
the planned activity schedules of the equipment Given the estimated raw requirements, the next step is to go to the 
upper level and estimate consolidated requirements, that is requirements as seen by ttie repair shop (assuming that 
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10 



IS 



20 



25 



30 



o^^ocation wiO send its repair requests to the repair shop. Tliis is analogous to the inventory 'fPle^^^ertpol- 
S^S^Ta^^SturirS^ "ndeckfngonthet^ 

eS^Thus. ^^^^ replenishn«nt policy o. the facility and estimates of rts ra. require 

ments,itsconsoBdated requirements can 1)6 estimated. . c»=««*^i 

The tojHloi-n esBmalion approach mal« use of historical data to ess 
lorecasSng techniques can be used to support this process. ^ „^ „.««riioH m 

^^wSmates obtained by boltonHjp and top<lo*n approaches are compared, analyzed and reconoled to 
g^^^^eTc^rsL^ repair requirements. The output of this process is the estimated consohdated 
requirements for an et^pment operating location. 

Requirements-S(4}ply Reconciliation Planning Process 

The second process is the Requirements^upply RecondBation Planning process 100 that ^'^^^^"^^ 
integrated repair plan^ the repair shop through a recond^ 
pofi^the^afrShoparetobedetennined. Aggregate repair reqJrem^ 

SfS reS S^^estimated consolidated requirements tor all ladlitiea The next step « to gen^atean 
repaJ on repair time estimates far each repairable part and the aggregate repair '^'^"'^^^^^^ 

SftL^egate repairpL is chected with respect to resource cona^ 
teJ^j^StrSri the agyegate repair plan is not feasilie with re^ 

SiS^S^^e^S^forwanlorbackw^ 

1^1^^ Specttoresource constraints is attained. The supply management102(seefB^^ 
S^iS^jTe^considering repair peopte. test equ^ 

a ttie aogregate roair pten into a detailed plan concerning repair resources (repair persons and test equpmenf). and 
^l^^ZTS^rTLed on these requirements and the capacity const^ 
S;^andWcomponents.adelaned repair plan is de^elope^ 
SSSSTepairpteL^ied^ generate the 1^ 
JSLTSn«swlyn^«^P«H«ss102isalso<^ 

S«rt^poriciesfortey<»np«.entsintennsrf 
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Basic Frames 



Thebasfc Frames 16of the presert oiv^ 

instarSs of Ihese Frames 16 in a particular DSS 10 '"^^^^^^^ tT^^tT 
the uTKlertyirig bosirtess processes, arxl the orga^ 
16 in the coritexl of rnariufacluririg arKl equipmeril re^ 
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Manufacturing Supply Chain 


Equipment Repair Supply 
Chain 


Demand Mamagement 


Requirements Management 


PSI Planning 


Requirements - Supply 
Reconciliation 


Supply Management 


Supply Management 


Vendor Managed 
Replenishment 




Finished Goods Distribution 
Network Design 





Table 6 

Decision Siipport Frames in the Context 
of Manufacturing and Equipment Repair Supply Chains 



25 SpedficHtion of the Basic Frames 

To specify each basic Firame 1 6. we use influence diagrams to map the modules in the Model Engine 20 and the 
Data Spaces to the frama We use process flow diagrams to outline the high le^ design of the lo^cal relationship 
among the data tdt>les. the modiJes and the basic Frames ia We also cfiscuss how to siwort key functional 
30 requirements in each frama To complete the specif icalion of the basic Frames 1 6. we data flow diagrams to map 
the data tables to the core reports in each frama The legend for the process and the data flw wiHbe 
cfiscussed herein after is shown in figure 10. 

E)enrand (Reqiirements) Management Frame 

35 

The Demand Management Frame 130 supports the demand management decision process descrft>ed hera 
Manufacturg)g Supply Chain 
40 Module and Data Space Association 

Figure 11 shows the partiqpating modiies and the associated data spaces for this frama 
The Demand Management Frame 130 requires the partidpation of two modules: the Sales Forecasting and Plan- 
ning (SFP) Modute 132 and the Market Data Analysis (MD^ module 134. The SFP Module 132 in the Demand Man- 
45 agernertFrarne 130 essertaDy operates in the Ddata space, i.a,ittransforrnsdalaw^ 

ctomain. Ihe MDA Module 134 in the Demand Management Frame 130 operates in the I and the D data spaces and 
relates the I data space to the D data space, i e., it may transform data within the individual D data space as weO as 
transform data from the I data space to the D data spaca The data space represerrtationcl the Den^^ Management 
Rame 1 30 is the uroon of the data space representations of each partkapating modula and the interactions anK>ng par- 
50 tkapating modiies. 

The high te^ representatkxi of figure 11 can be complemented by the process fkaw diagram for this frame, 
desoibed next, tfiat will detail the cormectkHis k>etween the constituent modules and the associated data tables. 

Process FhTw 

55 

The process ftow cfia^am for the Demand Management Frame 130 is shown in figure 12. The modules, data 
tables, and the principal acliNnties within the scope otf this frame are dearly nrarked by the grooved d^ border. 
Only the data tables that are updated by the frame are conskJered to be within the scope of the frame 130. Other 
frames, activities and data tables that are related are also shown for conpleteness. The Order Fulfillment 1 49, that is 
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out-of-scope of the Demand Management Frame 130 but related to it, is showi separately in figure 13 for purposes of 
darity. This representation of interaction between Frames 16 is consistent with the interaction between decision proc- 
esses shown in figure 8. 

The Demand Management Ftame 130 stpports the functional requirements described b^. Demand Character- 
ization- Demand data from various sources such as Demand History Data 136. POS Data 138, Mari«t Data 140. and 
Promotion Data 142 as well as top^town and botlonrHp Forecast Data 146 

wiD be consolidated and synthesized by the MDA Module 134 and the SFP Module 132. BottonHip Demand Forecast- 
ing - Demand Review 144 consolidates demand infonnation received directly from the customer along with the input 
from the MDA Module 134 and then de/elops Demand Orientation Data 148. The SFP Module 132 will then use 
Demand Orientation Data 148 as wefl as other inputs, ag. Promotion 142 and POS 138 Data, to develop the customer- 
centric bottonMjp forecaste in Forecast Data 146. Tofxlown Forecasting - The SFP Module 132 will use mari«t and 
industry-wide trend analysis performed by the MDA Module 134 along with the enterprise's shipment history to gener- 
ate the productKjentric tofxtown forecaste in Forecast Data 146. Sales Promotion Analysis - The MDA Module 134 
renews the demand history from POS Data 138 and Demand History Data 136 along with the customer promotion 
infomwtion from Promotion Date 142 to analyze the inpacl of promotions on sales. 

then used to help adjist sales forecasts to accomt for promotions. Forecast Performance Evalimtfon - Using Demand 
Orientation Data 146. Demand hfelory Data 136 and Promotion Data 142. the SFP 132 and MDA Module 134 can eval- 
uate the quafity of enterprise's forecasts and the customer projections. 

DataFlow 

The data flow diagram for the Demand Management Frame 130 is shown in f igure 1 4. The Demand Management 
Rame 130 generates two off the core reports listed eariier, namely, the Sales Plan 152 and the Customer-Demand His- 
tory 1 54. For each core report the associated data tables are shown. The dashed fine indicates the influence of an out- 
of-scope (with respect to the Demand Management Frame 1 30) date table in the development off the report. For exam- 
ple, the Customer Orders data table 150 is out-of-scope of the Demand Management Frame 130 but influences the 
Customer-Demand History report 152. 

Demand Management is the process in which the user determines future requirements based on past requirement 
history and general infomiatfon related to the supply chain. In the context of the manufacturing environment Demand 
Managemert stpporte the analysis of past dernand and off rnari«t trends as weU as the d 

For the repair enviroiwtenl the term Requirement Management is used in place off Demand Managen^ Requirement 
Management is the process where future requirements are estimated based on an analysis of each equipment's activity 
and on the projection off past requirement history. 

In the manufacturing context, Demand Management regroups the set of processes by which the user analyzes 
Mari^ Data 140 and past demand history for the purpose off estimating future demand requiremente. The outpute of 
Demand Management include the analysis of past hislory, futire forecasts, the analysis of special activities such as 
sates promotfons. and the analysts of forecast errors. Two critical outpute off Demand Management are two cfifferent 
mecfiun term forecasts corresponcBng to two dHfferent views on the dynamics of the processes that generate future 
re(»iiremente: the customer centric forecast - generated at the product le^ for ea^ 
malions off future demand prowded by each custorner (BotlomHjp Fbrec 

ated at the proAict l»fe!, it incorporates the inrpact off market and industry-wide trends on future demand for each 
product ^otp Oop^town Forecast). These two types off forecast are generated using: hfelorical projection off past 
demand; Future orders inforrnalfon: Analysts off the dynanrics and cha^ 
petitors; and Analysis off the irrpacl of future special confHnercial ac^ 
and projectfons a-e youped in five functional requrernente that are dela^ 

aclerization,BottonHjpDeinand Forecasting, TofHtownDernand Forecasting, Sales Promotion Arwiysis, and Forecast 
Performance Evatuatfon. 

Other frames such as production, sales and inventory (PSO or vendor managed replenishment (VMR) may directty 
or indirectty use the output of Demand Management 

Demand Characterization 

The objective off Demand Characterization is to provide the user with an environment where (s)he can access, ana- 
lyze and synthesize demand date from different sources. These data include: Sales Hislory data (that include POS and 
shipment data). Inventory date (relative to the inventory position of ite product at the ojstomer's stocking pointe), and 
Mariwt Data 140. Market Data 140 correspond to vario^ quantitative information, usually provided by external entities 
such as Nidsen. that relates to the sales for the type of product considered in the entire mari<et. 
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Acquire, Display. Ecfit Data 

Data Acquffiilion consists of selecting a Data Domain (specific pairs of customer and product), and choosing ttie 
type of data to t)e displayed (POS. demand history, inventory, Market Data 140). Data can be edited and modified and 
saved along with resuHs of analysis in a scenaria 

Analyze & Synthesize Data 
Sales History and Customer Inventory Data 
This involves the operations discussed k)efcw. 

Confute, display (1al)les and graphs), characterize and analyze sales history per product/|product group or cus- 
tamerVbustonwr yotp (see the MDA Module specification discussion for details of models and fonroilas): Vblatilrly of 
demand, Lunpiness of demand. Trends in demand history. Demand pattern changes, and Seasonality. 

CoiTpute, display (tal)les and graphs) and analyze sales history statistics for different levels of aggregation: Thfe 
y^ vs. last year, Actual sales vs. buc^^ and Year to date vs. t)alance of Year. 

Conpute, dsplay (tables and graphs), and analyze trend in Demand Product Mix by product groip. 

Pareto analysis of sales (or inventoiy) to identify ABC dassificalion for p^ specification for 

details of fonmlas). 

Conrpute and analyze corr^ation between the demand for cfifferent pro^^ 

Conpute, dsplay (tables and graphs), and analyze new products and model change-over prof fles. 

Conrpute, display (tables and graphs), and analyze inventory profile per customer. 

Conpute, dsplay (tables and graphs), and analyze trade inventory try comparing POS and shpment data. 

Market Data 

This operation involves the operations discussed bek3w. 

Display (tables and graphs) Market Data 1 40 (volume, value, market share) by product group, region, or customer 
group (Nielsen, ElA, etc.). 

Conpute, dsplay (tables and graphs) and analyze Mariffit Data 140 statistics for different levels of aggregation: 
This year vs. last year. Trend, Actual statistics va buc^ assumption, and Seasonality. 
Par^ analysis of corrpetitors (value and volume). 
Create price information: list of competitor products per price ranga 

Bottom-Up Demand Forecasting 

The objective of the Bottornnp forecasting is to devekp a custorner specif ic sal» 
ment to the customer, POS infornrwtion a* the customer k)cation, and the custom 
orders. 

Acquire, Display. Edt data. 

Data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing the 
type of data to be displayed: shipment or POS (when available). 

f=brecasts generated in the Bottom-ip forecasting frame can be saved back to the DSS Database 1 2 or alterna- 
tively saved as scenario. 

Bottonnp (BU) Forecast generation 

This operation involves the operations discussed betaw. 

Irput and maintain customer orders: Forward orders, and Orientation orders. 

Choose mod^ for statistical forecast 

Generate and display (tables and graphs) statistical forecast at different level of agyegation (POS or Shipment 
data) : Customer group, Individial customers for all products, arxf Indvidual customers for each product. 
Support integration in BU forecast of expert knowledge for optirT^tic/j;>essimistic forecast 
Formulate disaggregation \OQic of BU Forecast at customer level onto products. 
Incorporate iirpact of future pronKJftions for customer specific pronrxitions. 
Compute, dsplay and edt seasonality factors. 
Review actual seasonalrty against planned and "company" seasonalrty. 
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Disa«reaate yearly forecastsonto each period using seasonality factois at different levels of agflfe^o" (POS or 

'CTi^ S and ^) sales and forecast s«i^^ 
vear TOsvear VS. lasl year, and Aclual/forecast VS. Budget 

'^bll^JJS.l^arisa^F^ 

Invoke forec^s* accuracy estimation routine. 

Top-Down Forecasting 

TheobjectiveoftheTopKlo-^lorecastin^ 
data and industry analysis that accounts for markel-^wWe tre^ 

Acquire. Display, Ecft data. 

11,. dffl « »*«<in9 • <«» 0^ 

saved as a scenaria 
20 TofHtawn (TD) Forecast generation 

This operation involves the operations cfiscussed bekw. 

^"^SJd^S^Ss^'a^) statistics lorecast at tfrfferent .e,e. of aggregation (POS and Sh^ 
25 data): market lei«l. product groip level, and product line tewd. ,„ fnr-caBt 

Incorporate industry trend analysis developed in Demand CtiaracterizatM^ 
RjriiKilate disaggregation togic of TD Forecast at product level onto ci^ 

30 year. This year vs. last year, and Acti^Worecast vs. budget 
Confute, cfeplay and ecfit seasonality factors. 

RpvifiMraAal seasonality against planned and "company" seasonality. ^^/dtlq^t 
S^SS^^;^S!^onto eact, period using sea^ 

Shipment data): maritet level, product group level, and product line 
35 supportforecasting of model change over, and introduction of nw products. 

Invoke forecast accuracy eslimalion routine. 

Sales Promotion Analysis 

Ti« nK«rti»B Sates Piornotion Analysis is to analyze the inpact of promoB^ 

down sales forecasts. .... - . 

The finctional features associated vvilh Sales Promotion Analyse are given l)elovif. 

Maintain Promotion Calendar and add new promotions: Tmw^rfp-^^ and Class of oromotion 

Type of prornotion (defiled by who initiates the promotion: fimi. relaOer. competrtD^ 

(defined Ijy the nature of the promotional activity). D,«»».ii«ne 
lnte.3lyofpromotion:SearchandsoftprDmoBoncalendar.andAnabrzePastPromobons. 

Display sates data along with information of promotions under consideration. 

Establish profile for ihe impact of the sales promotions. 
Analv2eDromotion(s) effect through regression or time series models. 
^SrSayactualSattrlx.table to nom«l sales, seasonal effe^ 

Plan Future Promotions. ^ ^ r^«H 

Add promotion in promotion calendar - specify type. dass. intensity and t^i^ep^o^- 
Estimate irrpact d future promotion l)ased on the impact of simnar past pr^^ 
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Forecast Performance Evaluation 

The objective of Forecast Perfomiance Evaluation is to assess the accuracy of past sales forecasts. Forecast accu- 
racy is an inportant measure for several purposes: 
5 It helps the user to rdine the forecasting process by providing feedback on the abifily of cfifferent models and 
approaches to forecast future demand; 

It provides a measure of demand variabBity that is used to assess necessary safety stock; and 
H guides attention to those products and customers for which demand is difficull to forecast and that require special 
atterrtion. 

10 Two types of forecast perfonnance evaluations are considered: forecast accuracy of one particular version of the 
forec^ and average accuracy of n periocte ahead forecast 

The first forecast performance type provides point estimations of forecast accuracy, whfle the second one is an 
average estimation of the accuracy as a function of the number of period in advance a forecast is produced. 
The fmctional features associated with Forecast Performance Evaluation are given below. 
15 Select data domain. 

Confute and cSsplay Forecast errors for: Bottom up forecast Top down forecast and Sales plan (invoked from 
PSI). 

Maintain Accuracy Matrix for each type of forecast (table of the forecast accuracy n periods ahead). 
Generate exception report based on level of forecast error for different level of aggregation. 

20 

Equpment Repair Supply Chain 

In the context of the Equipment Repair Supply Chain the term "Requirements ManagemenT is used in place of 
"Demand ManagemenT to indicate that equipment generates "repair requirements" when it breaks down. 
25 Requirements Management is the process of estimating the future requirements of reparable items at the equip- 
ment tocation. This process can t>e cfivided into two main sub-processes: 

Evaluation of the raw requirements for each equipment; and 

Estimation of the consoGdated requirements at the le^^el of each location (several pieces of equipment can be 
30 tocatedattfiesamefocatfon). 

These two approaches can be used to estimate future consolidated requirenients. 

BottonHjp method: This approach uses a coiT4)ination of two models: (1) the first model estimates the raw require- 
ments of an equipment by modeling its faflure rate as a function of the equipinenfs activity (or usage) and (2) thesec- 
35 ond model estimates the consolidated requirement based on the raw requirements and the consolidation polk;y. 

Top down method: This approach is based on the projection of historical data for the consolidated demand. To sup- 
port tfie two different approaches the functional requirements detailed bek3w have been defined. 

Activity tracking for raw requirements estimation 

40 

This involves the operations cfiscussed befow. 
Select and Display Activity Data. 

Maintain Future Activity Data: Planned Equipment upgrade^naintenance schedules: and Planned Equipment 
usage schedules. 

45 

Analyze Past Activities 

Review activities: Display historical raw requirements data afong with activity data 
Assess inrpact of past activities using regression or time series models. 
50 Per type of equipment 
Per type of activity. 

Relate ftitire raw requirements to planned activities. 

Use nrK)dels of past activities to project the effect of future activities. 

55 Consolidated requirements estimation based on raw requirements (bottonKp) 

This operation involves the operations discussed betow. 
Select and Display Consolidated Requirement data. 

Fbmuilate. and r^ine consolidation policy (see SFP Module for explanation regarding consolidation policies). 
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Evaluate cfifferenl consdriation policies b^ed on past raw requirements. 
Estimate future consoOdated requirements based on chosen poficy. 

Consolidated requirements estimation based on historical data (to(Hiown) 

This involves the operations (fiscussed below. 
Select and Displ^ Consolidated Requirement data. 

Choose model lor statistical forecast of future usage per repair rtemfrepair item group. 

Kalman Rlter based algoritttn for requirements estimation (considered appropriate for forecasting equ?)ment fafl- 
ures). 

Other sta ti stical forecasting technk)ues. 

Generate and display (tables and graphs) statistical fore(^ at different level of aggregation: Repair item group. 
Incfividual Repair item for aD equpmert. and Individual Repair item for each equipment 

Coipute and display statistics (tables and graphs) for actual and estimated consoGdated requirements: Moving 
average, Year to date/balance of year. This year vs. last year, and Actual/forecast vs. Budget. 

Develop dfeagyegation logic of consolidated requirements estimation Forecast at repair item groi^) onto individual 
Repair item. Users can ovenride algorithm based estimates. Requirements reconciliation and requirements plan gener- 
ation 

This operation involves the operations cfiscussed below. 

Conpare and analyze top^fown said bottom-up requirements numerically and visually. 
Reconcile the top-cfown arxl bottom-tf> requirements to generate the requirements plan. 
Use weighted average models. 
Incorporate user's input and cverrida 

Requirements estimation performarKe evaluation 

Store top-down, bottom-up and reconciled rec^irements estimates. 

CoTTYXite and cfisplay Estimation errors for: Bottom up requirentent estimation. Top down requirement estimation, 
and Recondled requirement estimation. 

IWIaintain Accuiacy Matrix for each type of requirement estimation (table of the accuracy n periods ahead). 
Qeiierate exception report based on level of estimation accuracy for cfifferent level of aggregation. 

Production-Saies-lnventory Planning (Requirements-Supply Recondliation) F=rame 

The PSI Planning Frame 160 supports the PSI planning decision process described here. 

Module and Data Space Association 

Fi^e 15 shows tfie participating modules arvJ the associated data spaces for this franne. 

The PSI Planning Frame 160 requires the participation of three modules: the Sales Forecasting and Planrwng 
(SFP) Module 132. the Aggregate Production Planning (APP) Module 162, and the Finished Goods Inventory Manage- 
ment (FGIM) Module 164. The PSI Planning Frame 1 60 as a whole involves S, I. and D data spaces with iterative data 
transformations among each pair. 

Process Ftow 

Theprocessflowcfiagramfor the PSI Planning Frame 160 is shown in figure 16. The PSI Planning Frame 160 sip- 
ports the following functional requirenrients identified for the PSI pla^ 

Forecast ReconcOiation 

The Demand Management Frame 130 supplies the Forecast Date 146 (botlonHjp and tofxtown forecasts). The 
PSI Recondliation Activity 170 in concert with the SFP Module 132 revises the top-down forecaste and reconciles the 
boltom-tp and top-down forecasts. This is an iterative process which is shown as the "S" loop fin the top right quadrant 
) in the process ftow <fiagram. tf any changes to the bottom-up forecasts are warranted, the PSI Planning Frame 160 
interacts with the Dennnd Management Frame 1 30 to make the necessary changes. 
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Inventory Planning 

The PSI RecondFffition activity 1 70 in concert with the FGIM Module 1 64 detemunes the inventory requirenmnts in 
an iterative fashion. This is shown as the T loop fin the top left quadrant) in the process flow diagram. The inventory 
rec^irements are written to Inventory Data 182. The FGIM Module 164 as part of the PSI Planning Frame 160 also for- 
mulates the finished goods inventory poGdes; the policy parameters are written to Inventory Parameters 1 72. 

Supply Requirement Planning 

The PSI RecondBation Activity 170 in concert with the APP Module 160 determines the production recpjirements 
that are consistent with the sales plan and the inventory requirements in an iterative fashion. This is shown as the "P" 
loop On the txsttom right quadrant in the process flow cfiagram. The production requirements are written to Production 
Requirements Data 174. The APP Module 160 as part of the PSI Planning Frame 160 also checks aggregate produc- 
tion capacity and key component availat)irtty using F^uction Capacity Data 180 and Inventory Data 182 (component 
avaDability). 

Production-Sales-lnventory-Plan Coordination 

The PSI Recondliation Activity 1 70 interacts with the APP Module 1 60. the SFP Module 1 32, and the FGIM Module 
164 to coordinate the integrated production-sales-invenlory planning. This involves the evaluation of various plan 
options, checking the consistency of the constituent plans and resolving conflicts, if needed. 

DataFtow 

The data fk3w dagram for the PSI Planning Rame 160 shown in figure 17. The PSI Planning Frame 160 gener- 
ates the Production-Sales-lnventory Plan report 190 listed eariier. 

The Production-Sales-lnventory (PSQ Planning ts a process to reoondle demand and supply requirements in a 
supply chain. In the manufacturing environment the PSI Planning Frame 160 helps to reconcile production, sales and 
inventory requirement cfiscrepandes. In the repair environment the requirements-supply recondliation helps to recon- 
c9e requirements and supply. 

Maruxfacturing Supply Chain 

The PSI Planning Frame 160 sufsports the process that devetops an integrated productk>n-sales-inventory plan ior 
a selected product groif). The objective is to ensire that the result^ PSI plan 1 90 meets customer requrements and 
satisfies su|)ply capakxlity constraints and the inventory objective of the company. The current PSI plan 1 90 is cfisplayed 
together with a temporary PSI plan 190. The temporary PSI plan 190 can be imported from various data sources 
(indudmg data series from Scenarios 78). The user can then arwiyze and 

reference to the cun^ent PSI plan 190. The user can replace the cun^enl PSI plan 190 by the temporary one once the 
latter has been improved to satislactk)n. 

The RSI planrvng process requires the support of tfiree modules: the Sales Forecasting and Planning (SFP) Mod- 
ule 132, the Aggregate Production Planning (APP) Module 162 and the Finished Goods Inventory Management (FGIM) 
Module 164. 

Forecast RecondSatkm 

The Demand Management Frame 130 suppOes the Forecast Data 146 (bottomnp and top^lcwn forecasts) and an 
indlcatk)n ol the nrtethods used to generate them The user can use the sanrie methods to g 

compare the forecasts generated (Afferent methods. The user analyzes and recondles these forecasts to generate 
an appropriate set of sales requirements. The PSI Recondfiation 1 70, with the support of the SFP Module 1 32, revises 
forecasts and recondles top-down and bottom-up forecasts. 

Revise forecasts 

The forecast revision process acquires, displays, analyzes and edits the bottom-up or top<lcwn forecast The user 
first acquires forecasts generated i^ng different methocte from the Demand Management Frame 130. After analyzing 
these forecasts and comparing the results, the user then selects the most appropriate one to be used. The foDowing 
features are identified for this process: Acquire and d^play forecasts: Check forecast errors: Compute and display 
related statistics of sales: and Select forecasts. Individual desaiptions of these four features are as foltows. 
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Acqiure and disptev forecasts. 

This feature consisis of the following four steps: 

Choose product group: The user specifies the product groip of interest ^^^.^ 

Choose aggregation lewl: The user specifies the aggregation level (ag. month, year) for data display. 

tirport forecasts: The DSS 1 0 acquires the twttoiTHp and tojHto»m fc^^ 
Frame 130fortheselectedproductgron)fromtheDSSDatal)ase 12. ^ m rh«»n 

Display forecasts: The DSS 10 agyegatesWisaggregates as appropnate the forecasts to display at the chosen 
aggregation level. 

Check forecast emxs 

The forecast emx cheddng feahire supported t>y the SIT Module 132 computes and display 
ahead Wstorical errors of the bottooMp and top<lwni forecast 

Compute and display related stafistics of sales 

The sales statistics conputatfon feature sworted the SFP Module 132 computes: mean and variance ov^ a 
selected time interval, moving average; trend. andAx seasonality factoiB of any chosen sales 11 

several forms (graphical, tabular or txith). 
Select forecasts 

The forecast selection feature irteracts with the Demand Managemert Rame 130 to check bot^ 
from various sources and the result of various top^town forecast methods (e g. moving average, regre^, combina- 
tions, etc.) The user then chooses the inost appropriate set of boltonHjp and tof>do^ 
racy, statistics and corsistence with each other. 

Reconcile top-down and bottom-up forecasts 

The process of to(>down and bottonHp reconaliation checks the discrepancy between 1h^ 
necessary resolves the confTicts between the two forecasts to generate a more desirable sales forecast The followirfl 
features are prwided to support this process: Conpute the difference between topd^ 
Generate weighted average of toiMtown and bottom^p forecasts; and Manually ovenivnte tem^^ 
(see the screens discussed later herein). Individual descriptions of these three features are as foflows. 

ConmutB the daference between tofKtown and bottoimjp forecasts. ^ ^ ^. 

The difference bet««en to^Htown and bottonHp forecasts is confuted and display^ 

bdween the two forecasts. 

Generate weighted average of tojMtawn and bottonup forecasts. 

The corilicts between the toiKtown and boltoiiHp forecasts can be resolved ivusingawei^ 

to generate a new temporary sales forecast in ttie S' line 

Manually ovenwite temporary sales (SO line 

The user manually oven«»rilestheforecast on the S- line to adjust the sales forecast to reflect va^ 

of influential factors, ftr exanpte. at«ust sales forecasts to accourt for inrecoided or antidpated 



Inventory Planning 



The process of Inventory Planning supported by the FGIM Modute 164 and the Demand Managemert 

detemfties the frish goods inventory requirements. In inventory planning, the user first selects a product group. To he^ 
the user to select an appropriate inventory policy, the DSS 10 computes and displays various sales measures wm^^ 

characterize the sates pattern of the chosen product groups Fa example, a Min-Max policy might be appropnate for a 
oroduct group faring steady demand. The DSS 10 then, based on the inventory policy selected by the u^ 

managerial sales and senrice targets. detem«nes the policy parameters and inventory level requirement^ user can 
then modify the policy parameters and inventory level requirements to satisfy various managerial requirefl^ and pro- 
duction resources Omitatfons. The folfowing two feattf es are identified lot this functtonal requirement Fbmuilate fin- 
ished goods inventory policies; and Determine finished goods inventory requirements. 
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Formulate finished goocte inventory policies 

The fomwlation of finished goods inventory pdides invohfes the selectbn inverrtory poGdes for chosen product 
groups and specifying the conresponding poBcy parameters, ft is broken down into the foOowing features: Choose inven- 
tory poriciesfc)r product groups; Choose policy param^ers; and Compute estirrated inventory statistics. 

I ndividual descriptions ol these three features are as fbl taws. 

Choose inventory policies for product groups 

In this feature, the user select inventory policies for product groups based on the patterns off sales the product 
groups are facing. It involves the Ibllcwing three steps: Choose product group: The user specifies the product yoif)(s) 
off interest; Acquire the following sates measures from the E)emand Management Frame 1 30: Usage rate - last medium 
or slow moving, Lurrpiness - sparseness of significant demands, and Vblatility - coefficient off variation; and Select 
inventory poOcy: The user chooses among the following an inventory poOcy for the chosen prodjcl group(s) based on 
the sales informatkxi acquired. 

For single product ^oup with nor>-lumpy dennands: User-specified base-stock policy, Periodic review cost optimi- 
zation policy, and Pertod review model with service level constraints. 

For related muftple product groups (ag. groups sharing the same production resources.) with non-lumpy 
demands: Leveled Poficy. Synchronized Policy, and Optimal Policy. 

For single product group with lumpy demand: Maximum n-Period Coverage Policy. 

Choose policy param^ers 

The FQIM Modute 164 based on the service level constraints and managerial ot^ective (e.g. minimize inventory 
carrying cost with a stock out probability 0* at most 5%) detemrtines the pol^^ inventory 
poOcy chosen by the user. The user can then obsenre the results of the estimated inventory statistics and adjust the 
poKcy parameters as appropriata 

Corrpute estimated inventory statistics 

The estimated inventory statistics calculation feature supported by the FGIM Module 164 computes and (fisplays 
the following inventory related me^urements: average inventory level (as weeks of sales); expected stock-out proba- 
bility; sennce level p rate); inventory carrying cost; and total cost (inducfing production, inventory holding, stock out 
perwtty and transportation costs) for the chosen inventory policy and poBcy 

Detenrune flushed goods inventory requirements 

The FGIM Modute 164 based on the inventory policy and poBcy parameters detemtines the finished goods inven- 
tory requirements for the product groups. The user can then modifies the inventory level requirements as appropriate. 
The following features are ident^ for determining the finished goods inventory requirements: Compute and display 
invOTtory level at chosen agg3regalk)n level: Manually override inventory lev* 

at chosen aggregatfon level. 

The PSI Planning Rarne 160 supported tv the FGIM Modute 164 conputes the inventory le^ 

sen inventory poCdes and paranietefs. The resuft will be dfeplayed in the ten^ 

is done at a lower aggregation level than the chosen one for cfisplay, the corresp^ 

doneb^orecfisplay. 

Manually override inventory levels 

The user can manually overwrite inventory levels to refftect various managerial concerns. For example, the unavafl- 
abflity off proAJdion resources at certain periods requires the decrease in conesponding inventory levels or the sug- 
gested inventory level exceeds the given management target 

Supply Requirement Planning 

The supply requirement planning feature supported by the APP Module 160 he^ delenrtnes the production 
requirements that are consistent with the sales plan and the inventory requirements. It also checks the feastoifity of the 
production requirements with respect to production capacity and k^ component avafl^lity. In case of infeasftwBty. ttie 
feature will provide information about the cause of corresponding infeasfljility to the i©er. The user can then modiftes 
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sales requirements, increases available resources (production capacity or key corrponent availability) and/a prioritizes 
the sales requiremerrls and restricts attention to satisfy a reduced set of high priority sales requirements only in order 
to achieve feasibility. 

Determine production requirements to sustain sales 

The process of determining production requirenwits to sustain sales consists of the following two features: Gener- 
ate production requirements; and Manually oven»vrite the production requirements. Indivicfcjal descr^Jtions of these two 
features are as follows. 

Generate production requirements 

The production requirements generation feature supported by the APP Module 160 detennines the production 
requirements based on sales and inventory requirements. There inventory requirements may take two different forms: 
Inventory levels, or Safety stocks. 

In case of inventory level requirements, the production requirements are generated using the inventory balance for- 
mula (fiscussed herein. 

In case of safety slock inventory requirements, the user can choose one of the folkwing objectives to determine the 
production requirements: Minimize the maximum production capacity utiBzation; Minimize the maximum inventory level ; 
Minin^ze the total inventory level; and Minimize the total inventory cost Onventory hoWing and backtog penalty costs 
required)- 

The production requirements generated are displayed in the temporary production (P*) lina If result of sanity check 
^ at a tower aggregation level than the one chosen for display, aggregation will be done before displ^. 

Manually overwrite the production requirements 

The production requirements are modified to reflect various consideratfons. For exarrple. insufficient production 
resources during certain periods. 

Check aggregate production capacity & key component availability 

In the process of checking the feasibnity of sales, inventory and production requirements against the availabilrty of 
production c^)acrty and key cornponerrts. the foDowing features are identified Deline key components: Check sanity of 
a given set of sales requirements On S* line) and safely slock constraints; Check feasibility of production re(^irements 
Cm P line); and Update and cfisplay production capadly toad and key component availabilrty. Indivklual descriptions of 
these four features are as foUows- 

Define key components 

Each user d^ines a list of key components. wWch is recorded and can be modified whenever necessary. The list 
of aD conponenls ¥vhk*i are sorted according to thar availabfli^ 
mocfify the Psl of key components. 

Check sarwty of a given s^ of sales requirements On S' One) and safety stock Cm r line) cm te>b iiints 

The process of sanity check utflizes the capacity checking rnodel in the APP M^ 
duction requirements for the given set of the sales requireniente and saf«y st^ 

scope the capacity checkmg model appropriately through modffication of: ljocation(s). Procfocts or product groups, 
Time horizon. Production fines, and Key componentSw 

If the results of the capacity model are infeasWe. critical under-capacitated production resources and key compo- 
nents are suggested to the user for firther nrxxfif ications. 

Check feasbflily of production requirements Qn P' line) 

This process checks sanity of a given s^ of production requirements against the produ^ 
ponent availabOity. This is also supported by the capacity checking model in the APP Module 160. Similar to the previ- 
ous sanity check descrftjed above, the user chooses the appropriate scope of the capacity checking model and if it 
turrre out to be infeasWe. critical under-capacrtated production resources and key components are suggested to the 
user for further modiftoation. 
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Update and cfisplay prcxluction capacity load and key connponent avaitabO'rty 

After a few iterations of the sanity checks and capacity requirement acfi ustment the user can reach a fe^We set 
of production reqidrements. The remaining avaflaljle production capacity and key con^ 

(fisplayed if requested. The user can then accept a reject new producttonrequirenients based on the availability of pro- 
duction capacity arxl key components. 

Production-Sales-tnventory Plan Coofdination 

The coordination of the production-salesHnventory plan ensures consistency among the production, sales and 
inventory plans and helps determine a feasible and appropriate PSI plan 190. 

Check and ensure consistency in PSI plan 

The user can utaize this feature in either: the independent mode or the consistent mode. 

In the former mode, the iser can edit the production, sales and inventory requirements separately by disregarding 
any consistency requirement. In the latter mode, the DSS 1 0 always ensures the consistency of the production, sales 
and Inventory requirements. In the consistent mode, the following features are identified: Modify the plan according to 
the user defined sequerx^; Maintain the consistency in other lines due to the change of one line; Update the production 
(P), sales (S) and inventory (I) lines (see display figures discussed herein) by their conesponding temporary fines; 
Maintain consistency at different aggregation level (for either the consistent or independent modes onljO- Individual 
descriptions of these featu-es are as folfows. 

Modify the plan acoorcfing to the user defined sequence 

When the user fifst switches to the consistent mode, two of the temporary production, sales and inventory lines 
have to be selected to generate the third fine using the inventory balance formula d'scussed herein. 

Maintain the consistency in other fines due to the change of one line 

Whenever a temporary production, sales or inventory line is cvenwritlen, it will be modified together with one of the 
remaining two fines (pre-selected and can be re-selected anytime by the user) to maintain consistency. 

Update the production (P), sales (S) and inventory (0 lines by their con^esponcfing temporary lines 

The user can replace the set of P, S and I display lines (see display discussion herein) by a set of consistent P', 
and r fines. The P, S and I fines can always be saved as a scenarkx <>iV user with the appropri^ 
save the P. S and I fines to the DSS Database 12 permanently. 

Mairrtain consistency at cfifferent aggre^tion level 

The DSS 1 0 can cfisplay data at any resolution higher than the primary data resolutfon level. Whenever display at 
a hi^er resolution is nfKxlified, dfeaggre^tfon will be done to maintain consistency. The DSS 10 computes a set of 
default dtsaggregm^ ^ir. bast^ on cBristing lowest resolution data. The user can overwrite the disaggregatfon tofflc 
wtYenever appropriata 

Evaluate PSI plan options 

The PSI plan options evaluation featije confutes and cfisplays the perfonrnan^ 
PSI plan 190 for the user to conpare and choose a desirable one. The following two features are identified to support 
this feature: Convute relevant performance metrics; and Compare cfifferent plans. Individual descriptior^ of these two 
features are as foOows. 

Corrpute relevant performance metrics 

The foDowing performance metres are corrputed using the routines specified in the SFP 132, FQIM 164 and APP 
Module 160 to assist the user to select a more desirable versfon of the PSI plan 190: Total and breakdown of costs. 
Average inventory level. Average expected stock-outs. Expected Throughput Time, and Expected Service level. 
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Compare different plans 

Different PSI plans 190 over tfie same or different time periods togeltier witfi tfieir corresponcfing performance met- 
rics are displayed side by side for conparison purposes. 

Repair Environment 

In trie Repair Environment tfie term 'T^equirements-Siwly Reconciliation" is used in place of Produclion-Sales- 
Inventory planning. This reflects tfie fact tfwt tfiere is no production nor sales in a repair environment txjt "repair require- 
ments" and "repair supply" in tfte form of repair worislation capacity and component availal)ility. "Requiremwits-Supply 
Reconciliation" Planning is a reconciliation process that develops an integrated and feasfole plan. 

The Requirements-Supply Reconciliation comprises of two main processes: Estimation of the aggregate repair 
requirements based on the inventory position of senriceaUe parts at the repair location and the target level for this 
inventory; and Feasibflily assessment for the aggregate repair requirements under resource capacity (skflls and mttk- 
stations) and conrponent avaflability constraints. To support these processes the following functional requirements have 
been defined. 

Evaluate and propose Consolidated SennceaWe Inventory (CSI) Levels based on past usage and future usage 
requirements. 

The IbDowing operations are performed: R^ine variability and lumpiness estimates of usage; Refine repair lead 
tinte estimates; and Propose target CSI levelSw 

Detemrine Aggregate Repair Requirements 

TTiis includes using target CSI levels, and current inventory positions to determine aggregate repair requirem^its. 

Generate Aggregate Repair Plan 

Thfe includes the following: Verify repair resource capacities to satisfy aggregate repair requirements based on; 
repair personnel sMD sets; workstations features: Verify component avaflability to sattefy aggregate repair require- 
ments; and Generate aggregate repair plan under capacity and component constraints. 

Supply Management 

The Supply Management Frame 200 supports the Supply Management decision process. 
Module and Data Space Associatfon 

Figure 18 shows the partkapating nriodules and the associated data spaces for this Rranrie 200. 

Process Ffow 

The process ffow diagram for the supply planning frame 200 is shown in figure 19. The Supply Management Frame 
200 supports the foltowing functional requirements ktentif ied for the Supply Management decfeion process: 

Aggregate Productwn Planning 

The APP Module 160 works ctosely with the FGIM Module 164 and uses Inventory Data 182 and the Productfon 
Capacity Data 180 to evaluate production and inventory tradeoffs. The APP Module 160 also uses the Productfon 
Requirements Data 174 from the PSI Planning Frame 160 to generate aggregate production plans. These are written 
to the Aggregate Productfon Plan Data 202. 

Dynamfo Replanning 

The abrogate production plan is often modified by the APP Module 160 to reflect either changing productfon 
requirements provkJed by the PSI Planning Rame 160 through the Production Requirements Data 174 or changing 
conponenl avaS^ility from the Material Planning activity 210 through Material Delivery Schedule 212. 



27 



EP0770967A2 



Capacity Planning 

The APP Module 160 utilizes long-term Production Capacity Data 180 from the Product Planning activity 214, the 
production parameters such as process times from Production Matrix 216, and the planning biD-of-material for the prod- 
5 uct from Planning BOM 218 to determine the production capacity requirements. In so doing, the APP ModiJe 160 may 
evaluate a nunt)er of production capacity options such ^ various production line sfructures and allocation of 
resourcesw The capacity plan is written to Production Capacity Data 180. 

Conponent Procurement Policy Development 

10 

The Conponent Procurement Policy Development (CPPD) Module 230 re^news the long-term component require- 
ments in Conponent Requirement Data 232 and other relevant component supply inft)rmation to formulate component 
procurement policies. The conponent procurement policy parameters are then written to Component Supply Contract 
234. 

15 

The data flow diagrams fa the Sijpply Management Frame 200 are sh^ 21. The Supply 

Management Frame 200 generates the core report previously discussed, namely, the Master Production Plan 240 and 
20 the Production Capacity Plan 242. 

Vendor Managed Fteplenishment Frame 

The Vendor Managed Replenishment (VMR) Frame 250 supports the VMR decision process. 

25 

Module and Data Space Association 

The Data Space associations for Frame 250 are illustrated in figure 22. 
30 ProcessFlow 

The process flow (fiagram for the VMR Frame 250 is shown in fi^re 23. The VMR Frame 250 supports the func- 
tional requirements tdent^ for the VMR dedsfon process: 

35 VMR Sfrategic Planning. 

The VMR Strategic Planning activity 252 in concert with the MDAM^^ Module 164 considers 

the financial and business requirements supplied the customers, dfetribution inffrastmclure, POS history and the 
transportation factors in the Stpply Chain N^work data table 260 to evaluate various service confract options. The 
40 VMR contract parameters are then written to VMR Contract 262. 

Replenishment Planning 

The Replenishment Planning activity 270 working with the MDA 134 and ttte SFP Module 132 reviews the seO- 
45 throu^ information and provkles input to ttie FGIM Module 164 to generate ttie corresponding replenishment require- 
ments. These requirements are refined according to the VMR Contract 262. Based on ttiese inventory reqiirements. 
the VMR Contract 262 and the order fulffllment activity, the replenishment schedule is generated and written to VMR 
Data 272. 

50 Data Flow 

The data ftow cfiagram for the VMR Frame 250 is shown in figure 24. The VMR Frame 250 generates ttie Replen- 
ishment Schedule report 280 Bsled eartier. 

VMR. also referred to as direct replenishment is a growing agile logistics partnership agreement where tiie vendor 
55 takes on the responstoility of managing ttie inventory at ttie customer sites for ttie products it supplies, i.e. monitoring, 
planning, and directiy replenishing ttie inventory in ttie customw's distrfoution network. In ottiw words, und^ a VMR 
arrangement, it fettle venda who determines when stocks are to be replerashed and in rattier ttian 

respontfing passively to orders placed by the retailer. Ihts arrangement is usually typified by a contrort which specifies 
ttie financial ternis, inventory constraints, and performance targets such as servfoe measures. VMR is almost invariably 
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based on the avaflabilily of direct access to points-sale date and the customer's inventory positions. Such an anange- 
ment can be mutually advantegeous to the customer and the supplier. 

On the other hand, VMR requires the integration of inventory and transportation planning processes of the SMPpHer 
and the customer. Although much has been written in the general literature about VMR as a concept (e.g., W^l-Marfs 
retationshps with its suppfieiB) there are few kncwn quantitative Existing VMR systOTS 

are transaction oriented and provide little a no decision SMpport cap^ 

The VMR Irone 250 consols of a set of decision 6^)port tools that can be used m the development of VMR pro- 
grams. The features offered by the VMR Frame 250 support the decision making processes in ttie VMR programs at 
both strategic and operational levels. More specificalty. at ttie strategic level, tiie user can invoke the features provided 
tjy the Frame 250 to study of the feasibiGty of VMR programs; ©raluate ttie terms of VMR contracts; and periodically 
review the overaD performance of the VMR progmm. 

At the operational level, the user can invoke the Frame features to devetop sell-through forecasts; obtain suggested 
replenisJtnenl quantities: revise replenishment quantities; and monitor sates and otiier VMR related statistics. 

In ttiis section, we wiD provide the functional specification for the VMR Rame 250. The entire Frame 250 can be 
partitioned into three main parts: basic and VMR specific data maintenance, strategic planning and replenishment plan- 
ning. It supports the foOowing two functional requirements: VMR Strategic Planning: Evaluate financial and logistical 
tradeoffs in a VMR contract, and Comparative analysis of varfous service contract options; and Replenishment Plan- 
ning: Review sefl-ttvough and determine inventory requirements at retafler's kx»tion, and Formulate the replenishment 
plan. 

The main decision modules to si^ort the VMR Frame 250 include MDA 134, SFP 132, VMR and APP 160. We 
wiQ (fiscuss the functional specifications that are applicable to ttie manufacturing environment 

Data Maintenance 

To support general functionafity of ttie VMR Frame 250. ttie system shouW maintain two types of date: the Basic 
Structural Date and ttte Replenishment Data. In the following two sut>-sections we discuss the detaDs of these two sets 
of data. 

Basic Structural Data 

These include ttie essential date elements required to 6esafbe ttie basic characteristics of ttie products, distribu- 
tion network, etc. TWs set of date are relatively stable and require only infrequent updates (ag.. at ttie time when ttie 
VMR program is being initialized, or when new models are being added to the program). These include: 

Distrtoution Networic Define ttie customer as well as ttie vendor's product distrfoution networks ttiat are relevant to 
ttie VMR proyam. It identifies which product is being cfistributed from whfoh vendor warehouse and whfch cus- 
tomer Distribution Center (or store) are assigned to each warehouse. 

Distrfoution Center pC) Profile: Define ttie nriain attributes of a custonrier DC or a vendor warehouse inducfing i^ 
focation (city and state) information. 

Lead^mes: Defvie ttie lead-time for product (fistrftxition between a given pair of locations and ttie corresponcfing 
transportation modesw 

Transportation Costs: Define the transportation costs for product dislrfoution for given transportation modes. 
Product ProfBe: Define ttie main attrftxjtes of ttie products partici)ating in ttie VM IDs and 

physical char^rteristics. tt also specSies whether a product is currently in ttie VMR p 

Product Replacement Relationship: Define ttie relationship between a cun^ent product and its predecessor (being 

replaced). This provides ttie basic infonnation to estdbBsh a continuous dernand stream 

products. 

Replenishment Date 

Replenishment date are more dynamic, and record ttie details about ttie replenishment activities as well as ttie 
characteristics of ttie VMR program ilseH. These include: 

Product and DC Watch List A set of products and DCs ttiat are defined by ttie user 
so that any special movements or activities can be detected and reported. 

Seasonality Factors: The set of factors cakajlated by ttie system or provided user to characterize ttie basic 
seasonal f Actuation patterns in the sales cictivities 

Replenishment Ordere (Recepts. In-transft. Incomplete, etc.): The detailed order status information ttiat is 
recorded to capture the replenishment activities included in the program. 
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Maximum and Average Inventory Levels: The targeted maximum and av«age inventory levels specified in the VMR 
contract They can be used to monitor the current pwfonnance of the VMR program. 
Service Levels: The targeted customer service levels specified in the VMR contract 

Delivery F=requency: The deGvery frequency is defined t)y the user or the system and it specifies the frequency at 
which the prodiK;ts are repl^ished for a particular customer DC. 

Promotion Calendar: The calendar captures the relevant promotion activities. This information is then used to 
ensure that a sufficient additional amount is included in the regular replenishment quantity. 

Strategic Planning 

Strategy; planning features mainly support VMR decisions during the initial program se^; irrportant durir^ VMR 
contract negotiation stages. They are also useful to provide critical operating parameters. e.g., replenishment frequen- 
cies Rnally, they are also needed to conduct long-term performarx^e reviews. Therefore, the functions provided at the 
strategic level are addressing the issues which are of long-term importance, even though these decisions are net made 
so frequently. 

VMR Contract Setup 

During the initial stage of potential engagement in a VMR program, the corvlitions in the VMR contract are pro- 
posed, studed and negotiated. Under such circumstances, the user needs to evaluate the costs and benefits of many 
cfifferent program options. When the terms are confficting, tradeoffs have to be mada In additioa one also has to 
choose a set of operating parameters and procedures which optimize total cost measures whTe satisfying given con- 
straints. The features provided below are to support these decision making problems. 

For a product/product group, a customer DC, and a defivery frequency defined by the user, the system will provide 
the corrputed relationship between expected service level and maximum (average) inventory level. Such a relationship 
wiD also be us^ for the user to evaluate what-if Scenarios and can be used in other features in tfis Franie (e.g., the 
Replenishment Planning t>elow). 

Compute and display expected service level for the maximum inventory requirement defined by the i^r. 

Estirnate and cfisplay the proper inventory levd for a given service level delined by t^ 

When evaluating the optinrial VM R operating paraineters or conditions in ^ 
to either check the compatibOity of a set of constraints including service level, inventory level and defivery frequency, or 
select an optimal set of these parameters after the evatuatfon of all feasible combinatfons. 

To use this feature, the user first needs to cfKX)se the product/produ^ 

For a given replenishment scenario (a given set of delivery frequency, target inventory level and customer sennce 
level), the system wDl estimate the total cost including customer DC inventory carrying cost, transportation cost and 
manufacturing plant inventory carrying cost 

Differert replenishniert Scenarios can be generated based on differert values of del^^ 
inventory level and target customer service level. In order to compare these dWerent options without using total pro- 
jected costs like the one suggested in the feature above, the system wOl compute key statistics such as expected inven- 
tory levels at customer DCs and manufacturing plants. By comparing these statistfos, a better replenishment scenarb 
can k>e identMed. 

Contract Parameter Monitoring and VMR Program Review 

After a VMR program has been setup and the execution started, it requires constant monitoring of the key policy 
parameteirs and perfbrmarx^e measures. If there are sut>stantial changes, it is critical to report them k>ack to the users. 
This is because the optirnal operating paranieters in the VMR program set at the strategic lev^ under cer- 

tain assumptfons about these key inc&»tors. In ^kfition. periodcally. the management will be interested in the actual 
^ectiveness of the VMR program. To support such program reviews, the system will record and generate management 
reports regarding the actual performance of the VMR program compared to the inventory and customer service level 
targets set in the VMR contract. 

PeriodfcaDy (which can be delined by the user), the system will compute the nriean and standard deviation of the 
sell-through for a given product of a given customs DC. The resulting nurrtos can then be corrpared to the historical 
norm defined by the user, the quantitative modeling assurrptions, or recorded tiy the system. If the mean and standard 
deviation are outside of the defined range, then the user has to be infomied through a procfejct sales exception report 
or other sinBlar reports. The user will be asked to define the foOowing: Frequency of such evalualion; Historical norm of 
the mean and standard deviation; and The ranges of the mean and standard deviation. 

One of the key objectives of ariy VMR program is to reduce the total inventory levels at diff^ 
chain. The system wfll compute and record average inventory levels and compare it to maximum and average inventory 
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targetew The results can then be reported to ttie user as requested. 

When the inventory level of a given product^oduct groi4> at a customer DC is much Wgher than needed, part of 
the inventory should be considered as excess. The system will report the list of products whose inventories are in 
excess. These products then wfll be off the replenishment product list until the inventory levels relum to a normal range. 
During these periods, the production and many other logistics operations planning win have to t>e notified about the 
reduction in planned quantities. 

Replenishment Planning 

This is to support more operational decision problems on a regular basis after the VMR program has started its exe- 
cution. During this stage, the main concerns of the user wfll be shifted to those of a more operational flavor such as the 
generatfon and revision of the replenishment order to satisfy target customer service levels and maximum inventory 
constraints. In acfcfition. in order to ensure the validity of the decision support models and prepare the decfeion makers 
for changes in the market place, the system will monitor certain operational incBcators relating to the VM R program. The 
incficators and purpose of thfe nrwnitoring are (fistinctively different from the monitoring and review function offered at 
the strategic level. 

Sen-through and Demand Orientation Forecasts 

B^e we can start to use the system to generate replenishment orders, a set of sell-through forecasts have to be 
developed. We wiD use the models developed in SFP 132 using POS as the primary data source. On the other hand, 
the production planner at the nianufacluringverxJor needs to know longer term forecast 

To that end, the system aDows the user to devetop and examine not only the replenishment quantity of the next replen- 
ishment cyde but also to extend several periods ahead so that these longer term forecasts can also be estimated and 
used for other (e.g., manufacturing) planning purposes. 

Based on the sell-through data provided by the cuslorner for a given product/jproduct 
system ¥«I1 generate sell-through forecasts including rnean and standard deviation for any ^en procfoct at a c^ 
DC. The actual forecast algorithm wfll invoke an appropriate one specified in the SFP Module 132 which should con- 
skier trend, and seasonality among other bask; aspects of the data stream. In case of a product having too litHe sell- 
thfough history, the system will use the product replacement relationship delined to establish more continuous sell- 
through history. In addilfon, the system win also pennit the user to select an appropriate length of historical data to 
account for abnormal sates activities for the product. 

The system wBl also generate tonger term replenishment requirements for the demand orientatfon for a given prod- 
uct so that the user can plan for the tonger term demands for the product To generate mecfium to tong term forecasts, 
the system will first forecast the sefl^hrough for the specified time periods by invoking appropriate forecasting algo- 
rithms in the SFP Module 132. Thea a set of replenishment quantities wiU be generated using the replenishment algo- 
rithm in the VMR modula These replenishment quantities win then become the demand forecasts for the product 

Replenishment Order Generation 

The generation of replenishment orders is the main fundfonality of the replenishment planning of the VMR Frame 
250. The main objective of the funclkxiality is to provkie the user vwth an initial set ^ 

of products with the conskteration of the seO-through forecasts as well as VMR spedfc operating paranr^eters. The 
quantities wiU then be approved by the user and converted into actual purchase ord^ 

Based on the Ibrecasls of the future sett-through, user defined VMR operating parameters (ag., customer servk» 
level, maximum inventory level and delivery frequency), and other related indicators (ag.. last reported customer DC 
inventory leveO, the system win generate a suggested replenishment quantity for a future replenishment data 

If the product model year changes are re^dar, then it is necessary to treat ttie replenishment quantity needed for 
product (or VMR program) initializatfon and termination differently from the regular replenishments. Therefore, the 
above feature has to be modffied to be app5cable to these settings: 

Set Initial Replenishment Quantities: The main difference between the initial replenishment quantity setup and the 
regular one is that it may require adcfitional quantities to f iO customer DCs or stores. In adcWon. because there is 
no sell-through history available for these new products, the history for the replaced products wfll have to be used 
in the conrputatfon. It is also necessary to set a time frame for the computatfon algorithm to use a new products 
data when it accumulates enough data of its own. 

Balance-out at the End of a Season: At the end of a selling seasoa a product neecte to be phased out In such a 
situation, the system wfll not generate any further replenishment quantities for the product unless the user deckie 
to overwrite the suggested (zero) quantities for a special reason . 
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For a given customer DC, when the products are tong considered for replenishment, the system will help the user 
set joint replenishment orders so that the total cost for the replenishmwt Iwtch can be minimized. The tjasic logic is to 
axki or delete products included in a replenishment batch to optimally use the transportation means while maintaining 
satisfactory customer service level and inventory level. 
5 TTie system wfl! also automate the replenishment quantity generation for a sei of products selected by the user. 
This feature is useful especially when the nunnber of products in the VMR pro-am is relatively large and the user pre- 
sto work only on exceptional issues rather than examining the detaBs of each product's replenishment activities. 

Reptentshment Order Revision 

10 

After the initial replenishment quantity has been generated for each product the us^ may be interested in exam- 
irvng the entire or only a selected set of products to make sure that the soft infomiation can be r^lected in the actual 
replenishment orders. In adcfition, a number of constraints such as product availability and production capacity wfll also 
have to be taken into consideration. The objective of ttie features listed betaw is to help the user revise the replenish- 
75 ment orders with relevant analysis and search support tods. 

The user can d^e a s^ of exceptional report generation criteria so that the system can search for and display the 
products faffing into the ranga The sample user-defined criteria will irK:lude 

Mean and standard deviation exceeding certain Emits of the historical norm 

The customer DC inventory exceedng the maximum inventory le/el after the suggested replenishment quantity 
20 arrives 

For a given replenishmarTt quantity (either recommended by the system or input by the user), the system wiD esti- 
mate and cfisplay the probability of stock-oiits. To compute the prot^rty value, a search algorittim is needed in addi- 
tfon to the relationship between inventory quantity, customer servfoe level and delivery frequency The user can use the 
feature to evaluate whether the replenishment quantity suggested is satisfactory or not 
2s Most of the replenishment quantities discussed here are appropriate for non-pronrwtional sales. When a promotkxi 
for a product is planned, the user should be informed so that the final replenishment quantities can incorporate addi- 
tional quantities due to the promotfon. The objective of this feature is to identify promotion events during a given replen- 
ishment review period and help the user incorporate additional quantity for the events. 

B^e the replenishmenl orders can be finalized, the DSS 10 will make sure that the vendor can supply the 
30 required quantities in the specified tirrte frama If the replenishment order shipment date is ctose to the review date, then 
the product (finished goods) availabDrty will be checked; and if the shipment date is further into the future, then the pro- 
ductbn capacity w3l be examined. 

In order to property make tradeoffs between different replenishment Scenarios, the system will estimate the total 
cost (indufing the inventory and transportation among others) for a given set of replenishment quantities. The cost will 
35 be computed automatically as the user is making modifications in the replenishment orders. 

To reduce the transportation cost, a rough-cut trucMoad planning tool will be provided to the user so that the room 
left on a truck can be filled by other most-needed products for the same customer DC. The underiying togic is to build 
a truckfoad of shipment whenever it s possUa 

40 Sales Activity Monitoring and R^enishment Review 

The movement off product sales reflected in the selMhrough data wai have different impacts on the future replen- 
ishment activities as wefl as the methods used to generate recommended replenishment quantities. Therefore, the sys- 
tem wiD provide the nrK>nitoring and tracking capaftiaities for the user to b^ the sales changes. In addition, 
45 the operating param^ers specified in the contract wHI also be morvtored so that the user can be reminded wtienever 
the repteftishrnerrt quaritities are likely to exceed the Rnrtits in the 00 

The system win compute and nnaintain the historical nonns of rnean arKi standard 
ttiey can be conpared to tfie sirnilar quantities in the rnost recent periods. It is an in^ 
if the recem sales cteviate from the user specified ranges of the historical nomns. 
so The system will monitor wheth^ the suggested replenishment quantity is going to exceed the maximum inventory 
level alfowed in the VM R contract The user wfll then t>e rKitif ied to take further actioa 

On a regular basis, the system will record a set of tracking signals arxl conrpute forecast errors so that when siAy 
stantial changes occur, it should be reported t>ack to the i^er to take further action. 

55 Distrfoution Network Design 

The DistrOtxition Network Design Frame 290 supports the Distrfoution Networtc Design. 
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Module and Data Space Association 

Figure 25 shows the partk^ipating modules and the associated data spaces for this frama 
ProcessFlow 

The process f tow diayam for the Distrilxjtion Network Design Ftame 290 is shown in figure 26. The Dislnlxjtion 
Network Design Frame 290 supports the functional requirements identified for the Distrftxilion Network Design decision 
process: 

1. Distritxjtion Location Analysis 

The Rnished Gkxxis Network Design (FQDND) Module 292 works with the MDA Module 134 and the SFP 
Module 132 to detretop a forecast of aggregate long-temi demand which is then used to evaluate potential Distri- 
bution Center (DC) locations. The chosen DC locations are then written to Inventory Node 294. 

2. Distribution Network Optimization 

The FGDND Module 292 works in concert with the FQIM Module 1 64 to optimize the overall network configu- 
ration. The result of this optimizalion is the assignment of demand nodes to DCs and the assignment off productfon 
nodes to DCs. This information is then written to Sipply Chain Network 296. 

DataFkiw 

The data flow diagram for the Distribution Network Design Frame 290 is shown in figure 27. The Distributfon Net- 
work Design Frame 290 generates two of the core reports fisted earlier, namely, the Customer-DC Assignment 300 and 
the Supply-DC Assignment 302. 

Model Engine and the Modules 

In tWs subsection, the overall desi^ of the Model Engine 20 is introduced. The ot^ective. scope, and features of 
the seven constituent modules of the Model Engine 20 are (fiscussed. 

The Model En^ne 20 consists off a library off specialized quantitative models and analysis routines. To address the 
needs of a set off users, a Decision Siwort Frame calls and assembles th 
appropriate data. 

The nun4)er of models and analysis routines within the Model Engine 20 could be quite large by virtue of the mod- 
ular design and inherent compleodty off the DSS 1 0. To better manage the l^todel Engine 20. there is a need for logicalty 
grouping the models and analysis routines. Furthermore, these models and analysis routines support major dedsfon- 
making areas in a supply chain. Therefore, the models and analysis routines are grouped into seven modules corre- 
sponding to the principal dedsfon-maWng areas in the supply chai^ 

134; Sates Forecasting & Planning (SFP) 132; Vtendor Managed Reptenishment CVMR) 252. Rnished Goods Inventory 
Mariagement (FGIM) 164; Ag^^egate ProAJClion Planning (APP) 162; Component Procurement & Policy Devetopment 
(CPPD) 230; Hnished Goods Distributfon Network Design CFGDND) 292; A frame by virtoe of its definition may require 
the participation off some subs^ off modules fi.a, the nriodels a^ 

In the case off the PSI Planning Fiame 160. the MDA 134. SFP 132. FGIM 164. and APP 160 Modules will be invoked 
in constitutirig the ctodsfon fogfo 76. 

In many cases, the same models and analysis routines may be ervpfoyed by distinct frames in different contexts, 
where the relationships b^ween the models and the associated data Bnkagre 

Supply Chain Frame Manager 24 interact directly with the rnodels and analysis routines m the Mode! En^ne 20. The 
models and analysis routines will therefore have standard data and logic irputfoulput (I/O) formats. The standard I/O 
formats will also fadlrtate the maintenance of the incfividual models and analysis routines, e.g., updating and replace- 
.merrt 

In addition to the seven modules d^ed above, there is also a group of general purpose numerical routines that 
are not specific to any of the^bove seven modules. These routines are collected into a design element referred to as 
the Model Engine UtDities 22. as shown In figure 1 . Examples of the Model Engine Utilities 22 include generic linear pro- 
gramrnng solvers, and statistical analysis routines. 

Table 7 lists the modutes in the DSS architecture for the two supply chains. 



33 



EP0770967A2 



McUiutacturing Supply 
Chain 


Equipment Repair Supply 
Chain 


Market Data Analysis 
(MDA) 


Market Data Analysis 
(MDA) 


Sales Forecasting & 
Planning (SFP) 


Sales Forecasting & 
Planning (SFP) 


Finished Goods 
Inventory Management 
(FGIM) 


Finished Goods Inventory 
Mamagement ( FGIM ) 


Aggregate Production 
Planning (APP) 


Aggregate Production 
Planning (APP) 


Component Procurement & 
Policy Development 
(CPPD) 


Component Procurement & 
Policy Development (CPPD) 


Vendor Managed 
Replenishment (VMR) 




Finished Goods 
Distribution Network 
Design (FGDND) 





Table 7 

Modules in the Manufacturing and Equipment 
Repair Supply Chain 



Market Date Analysis (MD^ 134 

The MDA Module 134 curtains quantitative models and computational routines that compile and synthesize hybrid 
sources of market information to stpport Sales Forecasting & Planning, and VMR. The models and routines of the MDA 
Module 134 are used in support of Demand Characterization, Bottom-up Forecasting, Top^iown Forecasting, Sales 
Promotion Analysis and Vendor Managed Replenishment The models and tiie routines in this module are used to: 
Analyze relevant industry data from various sources; and Provkie quantitative analyses d sales. 

Scope and objective 

Objective: CompOe and synthesize hybrid sources of market informatx)n for the purpose of sales forecasting and 
planning, and VMR. 

Scope: Intfeistry-wide, company ^)ec9k; and point-of-sale data. 

Features: Analyze relevant industry data from sources such as NGelsen and EtA (Electronk^s Industry Assodation); 
Devek)p customer and customer/k)roduct profiles; Maintain promotion calendars of major customer and the enterprise; 
analyze promotional effects; and Provkie quantitative artalyses of sales at retail outiets whenever point-of-sale data are 
avaSabIa 

Demand Characterization 

The models and routines in the MDA 134 module to support demand characterization in the commercial setting are 
equally applicat)le to support requirements characterization in the defense setting. 

For national defense applk^ations, the actual repair item usage data correspond to the POS Data 138 in the com- 
mercial setting. Analysis for POS Data 138 can t)e performed on the repair item u^ 

various parts. Furthemiore, in order to intuitively access relevant repair item-related data and information, the relation- 
ship among efferent parts has to be established. To that end, we will devek)p a tree structure to represent the bill of 
material where each node of the tree oorresponctetoa repair item, and each arc represents a parent-chiW relationsh^). 
For ease of presentation we enrpfoy commercial nomenclature in the foHcwing sectioa 
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Analysts Routines for Demand Characterization 

In the following, we descnbe three types of analyses that will b& pefformed on industry survey data. Demand His- 
tory Data 136, and Point-Of-Sales Data 138 to characterize the demand for the products (or services in defense appfi- 
5 cations). There are other types of analysis that can be performed on these data sets wrt 
wtten each individual data set is t>eing considered. 

Product Family Corrposition Trend and Percentage 

10 This involves the analysis of the trends in quantity and percentage of each product family over a given period of 
time of the time series. The irputof the analysis routine is the set of time series corresponding to the product famDies 
and the associated product famfly names. The output is the trend of the quantity, and ca 

individual product famfly. Fior example. Table 5 below provides the percentage changes for major color televiston prod- 
uct famBles (13"-14", 15"-24". 25", 26" and 27" & above televisions) from 1988 to 1994. 

IS 





13'- 


15 




25' 


U" 


27 


' + 


1986 


24 


776* 


55. 


87*f 


6.05% 




6. 


18^ 


1989 


24 


.98^ 


54. 


86^ 


7.28% 


i.Oli 


7. 


87* 


1990 


22 


.12% 


54- 


79% 


8.06% 


4.56% 


10. 


47% 


1991 




.08^ 


49. 


-53* 


10.53% 


3.90% 


12. 




1992 


20 


.62^ 


48. 


T8i 


13.29% 


3.40% 


14. 


51* 


1^93 


19 


7i3k 


45. 


■l2i 


15.87% 


2.10% 


17. 


"7i* 


1994 


18 


.571 


41 


.58% 


17.58% 


1.55% 


20. 


71* 



^ Table 8 

Sanple Product Family Cotrqposition Change from 1988-1994 

30 

Pareto Analysis of Sales 

The analysis involves the plotting of the percentage cumulative sales levels vs. the percentage of total number of 
35 producls to determine the ABC classification of each product as inustrated in figure 29. 

Objective 

To ideritify the producls or custoriier that contrttxrte the rnosl to the volume. To establish 

40 the ABC Classification Of products (or customers). 

Input 

POS Data 138, Shipment or production data. 

45 

Output 

Ptot of tfie curvtidative p^c^rtage sales (or prochiction) levels vs^ 
tomer generating this sales (see figure 29). 

50 

Algorithmic Steps 

Rank producls or (customers) in deaeasi ng order of sales. 
Starting from the top of the Est compute: 

55 

cumulative sales 

cumulative number of product (or customers) 

Plotpercentageof cumulative sales as a function of percentage of total numl)er of products (or customers). 
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In addHion, another scatter plot can be drawn to show the volatility vs. sales (where measure of the volatility Is the 
coefftdentof variation) as shown in figure 30. Each poi^ 

and the result of these two plots can be used to develop differentiated inventory control policies tor products with differ- 
ent demand patterns. 

Correiatfon Analysis Among Product lilies 

This involves the analysis of the correlation among the ti^ 
irput of the aralysis routine is the set of time series con-esponding to the product families and the associated product 
family names. Itie output is the correlation coefficient for related product families. 

Industry Survey (El^ Data 

Bectronics Industry Association (EWQ coOects marujfaclurer to retailer Demand History Data 136 monthly from all 
major consumer electronics manufacturers. After consoOdation by EIA. the data are sent back to the manufacturers for 
theirown usage in analyzing industry wide sell-in activities. The data may be obscured by tenporary stocking and other 
short-tenn dealings between indivkJual manufacturers and relaflers. and they are usually a few months lata Therefore, 
the data are normaDy not suitable for short tenri demand characterization and fore^ 

data are useful in reveafing trends and changes in the sales of overall and incfividual product families. The three types 
of analyse descrtoed herein can be perfonried on the EIA data to monitor the ^ 

changes. 

Demand History Data 

INtot all retailers are capdWe of coDecting and providing the POS Data 138 to their manufacturer suppOers. For this 
reason, more traditional Demand History Data 1 36 shouW be analyzed to charact^e the demand for the manufac- 
turer^ products. We realize that the dennand data are a reflection of tt^ 
nunt)er ol factors. Fw instance, merting the quarter-end sales target or ^ 

deals may make true consumer demand fcjr the products less apparent Nevertheless, the Demand History Data 136 
are an inportart source of dernandinfornriatton that can cornplenfi^ information from tiie anal- 

ysis of POS Data 1 38 and the long tenm demand information obtained from EIA data. In general. Demand History Data 
136 are more suit^e to analyze the mecfium term sales level and trend information. The three analysis routines 
described herein can be applied to the Demand History Data 136 to derive the mecfium term sales level and trend 
change information. 

Point-of-Sales (POS) Dafa 

Major retailers are now coOecting the sates transaction data from the scanners at the sales counter and sending 
the data to their manufacturer suppliers after s ur rwnarization. The data (firectty reflect the consumer demand for the 
manufacturers products and response to sales promotions. They can serve as signals to the changes in sales trend 
and consumer reactions to mart«^ng efforts. In essence, the POS Date 138 can be used to detect sh^ 
ete and their changes for the manufacturer^ products at varkxjs retailing outiets. The three types of analyses descrft)ed 
herein cai be performed on the POS Data 138 to morwtor the short terni demand levels and their ongoing changes. 

The OTvenlory status represented in the POS ShouW be verified in order to be used to assess the supply chain fin- 
ished goods inventory situatioa Stvpment quantities from the manufacturer to the retailer are determined by consumer 
demand, and retailer's inventory carrying poBdes. among ottier infhiential factors while the POS Data 138 are much 
more direct in reflecting the tnie consumer demand. The following three analysis routines will be applied to POS Data 
138 in adcfition to the three general ones mentioned herein. 

Inventory Status Verfffoation 

To verify the inventory status, the POS Data 1 38 can be used in coirt)ination with the shipment data, and the inven- 
tory balance ecpjation to conpute the deduced inventory status. Then, the deduced inventory status can be conpared 
to the reported inventory status. 

Inventory Profile 

The inventory profile corresponds usuaOy to the management decision of an organization, and can be used to 
judge the over- and under-stocking situation along the supply chain. The normal inventory profile for each product and 
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customer combination will be caph^ed and stored so that it can be later retrieved and compared to the current and 
future (projected) inventory profiles to determine the possible ever- and under-stocking situations. 

Detection of the Changes in POS Data 

The normal sales levrels and associated variance intervals can be either calculated from the POS Data 138 for a 
given product by a customer, or specified by a user who is knowledgeable about the sales activities for the product. 
When the sales level fluctuates beyond the normal sales variance intervals, the tool can detect and report the excep- 
tions automatically. 

NADtablrty of demand 

Ot)jective 

To measure the votetility of demand. The volatflity of demand can be measured by the coefficient of variation off the 
den^nd. The coeffidenl of variatkxi of a random variable is equal to the ratio of the standard deviatkxi to the mean. A 
large value of the coelf kaent of variation incficates that the standard deviation is larger than the mean; the demand is 
therefore very volatile. While a small value of the coefficient of variation incficates a stable demand (taw levels of vola- 
tflity). 

Input 

POS Data 1 38 or Shipnriert data by product (product group) or customer (cuslon^ 
25 Output 

Vbtatifity measure Cs- 
Algorithmic Steps 

50 

Compute mean of demand: 



35 




40 



45 



Compute Standard devialnn of demand: 



Compute coe^ent of variation: 



50 



^ s 



Lumpiness of demand 
Ok^ective 

To measure the level of lumpiness of demand. The lumpiness is a measure of the time dispersion of demand. A 
demand pattern is said to be lumpy when the demand is concentrated in only a few number of time periods with numer- 
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ous periods wrth no demand. 
Input 

5 POS E)ata 138or Shpmenrt data by product (product group) or o^tomer (customer group) 
Output 

the lumpiness nneasura 

10 

Algorithniic Steps 

d ;s the percentage of the total number of time periocte with denri^ 
75 Demand pattern changes 
Ot)jective 

To d^ect rapid changes in level and variat)iKty of sales. 

20 

Input 

POS Data 1 38 or Shpment data product (product group) or customer (customer group). 
Range for ''normaT sales level and variatMTrty. 

25 

Output 

Exception signal indicatirtg a normal change in sales levels. 
30 Algorithmic Steps 

Conpute normal sales levels and associated variance from the POS Data 138 for a given product by a custom^^ 
Altemativeiy user s^ rar^e for normal sales le^ and variability. 
Corrpute actual level of sales and variance each period, 
as When the sales level fluctuates beyond the nonmal sales variance intervals, d^ect and report the exceptions. 

Demand history trend 

Objective 

40 

To characterize demand by trend arxi level parameters. To assess changes in the dynamics of demand based on 
changes in trend. 

Input 

45 

POS Data 138 or Shpmert data ty product (product group) or customer (customs 
Output 

50 EstinfttAion of trend and level. 
Algorithmic Steps 

For variable Xt over time period 1=0 to n. 

55 
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Compute trend (b) and level (a) paiameters: 



MODEL 


WHERE USED 


Volatility oi demand 


Demand Characterization 

PSI 

VMR 


Lumpiness of demand 


Demand Characterization 

PSI 

VMR 


Demand pattern changes 


Demand Characterization 
Bottom-up Forecast 
Top-down Forecast 
VMR 


Demand history trend 


Demand Characterization 


Pareto analysis 


Demand Characterization 
PSI 



Table 9 
Usage of MDA Models 



Sales Forecasting and Planning (SFP) 132 

The Sales Forecasting and Planning Module 1 32 contains all the models and routines ttiat are used to generate 
forecasts. These models and routines are used in the Demand Management Frame 1 30 for Boltom-i^^ Tofxfown fore- 
casting, for the analysis of sales promotions and to estimate forecast accur^^ 

VMRFirame290. . 

The models and routines of SFP 132 faU into three categories: generic models common to the manufachmng and 
repair environments; models specific to the manufacturing environment; and models specific to the repair environment. 

Scope and objective 

Objective: Develop topKfown and t)ottonrMjp sales foreca^ 
Scope: Products and selected customers. 
Features: Statistical forecast Ijased oi hislarkal sales; Statistk^ 
Customer provided forecast and orientelions: and Recondiiatiw 
tion flags and sanity checks. 

Models Common to Manufacturing and Repair Environments 

Three types of generic models are common to the manufacturing and repair environments. Thefirst type consists 
of the various statistical forecasting models that can be used to forecast any time series (demand or consolidated 
rec^rernert). The second type concerns the estimation of seasonality factors bas^ 
repair and the manufacturing environments. The third type of model relates to forecast accuracy estimation. 

Statistical Forecast Modete 

The objective of the Statistical modete is to generate a forecast based on the project 
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teri^ of the time series. These models can be applied to 
bottorTHip. tofHiown forecasls and VMR. 

Below we cfiscuss the foOownng models: Moving average; Linear trend; Bcponental smoothing; Hoft-Winters model; 
Winter's method; Regression based ftxecasling model; and AutoregressiveMwving average model (Box Jenkins). 

Moving Average 

This conventional model is appropriate when the dependent variable is assumed to fluctuate around a constant 
(stationary average value, i.e.: 

w^here pis an mknownconslart corresponding to the mean dfr^ zero and 

variance o2. Moreover, the mode! assumes that the variables {ej and hence {XJ are independent 



input 



Time series data to be forecasted (for example POS a shipment) 
Window n: nunto of periods to t}e considered for averaging. 



Output 

Future forecasts and their variances. 
25 Algorithmic Steps. 

Conpute next period forecast based on the average of the last n periods 



30 



35 Estimate for : 



40 



45 

Linear Trend 



var (F^i - Xj^i) := a^(m.1)/h. estimated by a^((n^.1)^) 



This conventional model is appropriate wh«i the dependert (forecastable) variable is assu^ 
a trend fine, specified as a linear formulation of time, i.a X , = a + b.t+ e , where et is a random error with mean zero and 
so variance o2. As above, {6, } and hence {XJ are assumed to be independent The model m^ 
of the regression based models below, with Time" as the only explanatory va 

Input 

55 Time series data to be forecasted (for example POS a shipment) window n. 
Output 

Future forecasls and their variances. 
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AlgorithiTuc Steps. 

Select appropriate time peri(xJfortrefxJestinra4k)ri(the>nridow"of 
5 Corrpute trervj and level parameters: 



70 



2>=n J: (i-t*n)X,-n-i^^ 



IS 



a^=p-i>(n+l)/2]/ 



6 4 



20 



25 



30 



Estimate forecast k>ased on trend projection 



Estimate variar)ce of forecast 



F^^i=a+b(t+1) 



Exporiential Smoothing 



40 



This conventional model is appropriate when the dependent variat)le is assumed to fluctuate around a constant 
(^ationar^ average value, i.e. : 

It puts progressively smaller weighls on nwe remote observations 

F^^, = aX, + a(1-a)Xi.i + a(1-a)^ + • 



Input 

Time series data to k>e forecasted (tor example POS or sh^>ment) 
45 Smoottiing parameter a 

CXriput 

Future forecasts and their variances. 

50 

Algorithmic Steps. 
Initiate F^ as Dq. 

55 • F^^1 =aDt + (1-a)F,. 

Estimate variance of forecast 
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2 2 

Estimate variance of forecasr error = N^r (F,^, - X,^i) = (a ) /{2-a) 



Hott-Winters model 



70 This conventional model is also wropnate when the dependent (forecaslal)le) variat)le assumed to fluctuate 
around a linear trend line, i.a when X, is specified by: 

X| =a + b.t4- e, 

IS vinth the associated asswnptions regarding a As with exponent 
uted to nwre remote observations. 

Irputs 

20 Time Series Data to l>e forecasted (for example POS or Shipment). 
Smoothing parameters 1 >a^>0. 

Outputs 

25 Future forecasts and their variances. 
Algorithmic Steps 

Iritial St> and C3o. irtlercept and Elope of trend line. 
30 Ujpdate recusively 

S, = '~aX,+(1-a)St,i+Q,.i 
Qt = P(St-S,.i) + (1-p)G,.i 

35 

Set 

40 Pt«=S, + xG, 

F^ = aD^ + a(1+p) (1-a) X^, + a(1-a) (1-a-aP) X^,^ + a(l-a-ap) (1-a)^ X,"3 + a{1-a-ap) (1-a)^X,^ 



45 



50 



\far (FJ = a^{a^ + {1+p)^ + a(1-a-ap)^(1-a)^/(2-a)) 

Estimate variance Of forecast by 

t-i 
t-1 i„i 



Estimate variance of forecast error t^: 

Var (F,^i - D^O = + (Up)^ (l-a)^ + {a(^-cL-apf(^^a)^V^2•a)] 
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Winters method 

Jhts conventional mode! is appropriate when the dependent (forecastaWe) variat)le is assumed to fluctuate around 
a linear trend line modulated by seasonality factors. i.e. 

5 

X, = (ji+Gt)Ct + e, 

ji is the initial deseasonafized level, G the trend or slope component and c, the muttiplicalive seasonality factor . Assume 
thai the season consists of N periods, i.aq = q+Nfo«^a^lt. The seasonality factors are normalized such that: 

10 

N 

15 Winters' method uses three smoothing factors, a, p and y as follcws: 
Inputs: 

Time Series Data to be forecasted (for example POS- or shipment). 
20 Season length N. 

Smoothing factors, a, p arxi Y- 

Outputs 

25 Future forecasts and their variances. 
Algorithm Steps 

Step 1 : (Initializalion). Use first two seasons (periocte - 2fU^ , -2t4+2 0) to initialize values: 

1a: CalciJate sample means for two separate seasons of data. 

-iir 



30 



35 



40 



lb: Define Gq = (V2 - VI )/N as the initial slope estimate. 
1c:SelSo = V2 + C^(N-1)/2. as an estimate of the value of the series at time t^. 
45 id:Con^xjteinitialestimalesof6ea5onalfaclors;theseareoblainedby(^ 
bf the corresponding point on the line connecting and Vg. i.e. compute: 

C| = Xj/[(V, - (NM-1)/2h)Go1. i = -2W*.1.....0 

50 ie: Average seasonal factors as computed for the two seasons 



55 



^t Normalize seasonal factors: 
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step 2: Update recursively: 

S, = a(X^C^) + (1-a) (X,.i+ G,.,) 
G, = P[S,-Sh1 + (1-P)G,.i 
C, = YPt^i) + (1-Y)C,44 
15 Step 3: Create forward forecast in period t for period t+r. 

Regression t>ased forecasting models 

20 

In this conventional model, it is assumed that the torecastable variable X is determined by m(21) eocogenously 
measurable (forecaslable) variables 2f^...2P'^ as follows: 

X, = a + bi Zf^', + Z« , b^Z^™' , + E, 

25 

where {ej are independent with mean zero and variance o^. 
Inputs 

30 Time series for py and ail explanatory varialjles Z^V •^'"^ Por example market share, total martlet value. 

installed t>ase, GNP, eto. 

Time series data to be Ibrecasted (for example POS or shpment) 

Outputs 

35 

Estimates of coeffiderrts a, bi.b2,...,b|n as well as o2. ^\ ^ ^ 

Forecast for future value of X on the basis of estimated future values of Z^^', Z^v..,?'"'. 

Algorithm Steps 

40 

Use of standard multiple regression method. 

Autoreg^essive / Moving average model (Box Jenkins) 

45 inlhiscategoryofmodels.itisas6urnedthalthefbrecaslaWevariable{Xt)exW 
most genera) model of this type is spec^ as an ARMA (p,q) 
model. i.e. 

= P 1 + P 2 + -Pp ^t-p + 

50 

Where 

= T 1 Cm + T 2 et.2 + Tq Ch, + "t 

ss with (uj independent with mean zero and variance o^. 
Inputs 

Time series data to be forecasted {for example POS or shipment). 
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Outputs 

Identification (rf optimal values of p and q. 

estinrales of coefficients Pi Ppandyi. ..Tq^weOaso^. 

5 Forecast of future valu& 

Algorithmic Steps 

Standard Box^enkins Algorithm and Process with forecasted value computed as follows: 

10 



15 

Seasonality factors estimation 
Objective 

20 

. To estimate for each time bucket (quarter, month, week) its percentage Of the yearly^ 
Input 

25 Histonc data by aggregated at the same level as the seasonality 
POS 

Shpment 

Total mark^ volume, elto. 

30 Output 

Seasonafity factors for each time bucket. 
Algorithrrac Steps 

35 

Confute for each time bucket the proportion of the yearly volume ft represents. 

Forecast Acct^acy Modete 

40 To estimate the accuracy Of the varkxfi types of forecasts Measures of forecast accuracy are u 
texts. 

ft is a proxy measure for the variance of the forecast when this one cannot directly be coripu^ Forecast variance 
is used in sei^ inveritory and safety stock cak»lation& 

Forecast error measures can also be used to identified those products and customers for which demand patterns 
45 are particulartyiffistable and thus require special attentioa 

Forecast error calculation 

Ot)iective 

50 

To compute forecast error for the forecast produced n periods ahead- 
Input 

55 Actual Sales 

n periods ahead Sales Forecast (BU, TP. etc.). 
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5 



10 



15 



Output 

Average Absohrte Error as Of percentage 
Mean Square Error 

Table of forecast accuracy as function of n 
Algorithnvc Steps 

Coopute the percentage difference between the forecasted and actual sales. 
Conpute average absolute error and rnean square forecast error. 

Exception report generation 
Ol)jective 

Tog«^lhefis.o,theproduc.sorcustomersfc.w«^ 
cast error threshold. 



Input 



20 



Average Absolute Error 
Mean Square Error 
Forecast error threshold 

25 Algorithmic Steps 

Ftok Bst in deaeasing order of Average Absdute Error or Mean Square Errw 



Output 

" Exceplionlistoaleredlistofproductsibrwhichthefc^ 
Models Spedffic to the Manufacturing Environment 

are also proposed. 
40 Expert based model for Bottonwjp forecast 

45 ^ted over all accounts. ^ u^^^^t'cnntirinated sales oattem for a given model, 

The analysis starts witl> a replenishmert 
1t» manufacturer are obtained as cler««ln«s of tte 

poBc,. W««dt^«.eacaojm^^ retaHer^ t,ehavoricr. 

lems) is an inportart assumption '"^ "^.^^r" ^lal the acoRints' sales pattern is much more pre- 

Pr«nous investigations of P"'*^ the iS^ng process with a 
dictable and ^^9^ «^ «^°^Xe2^^ 

characterization of the accounts sales reor«entatives (txiyers. logistics manag- 

The need to characterize the uncertamty of fte "'^^.^^'^fXT^i^ the so^alled l-One or 
Quick Response targets. 



50 



55 
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To assess miramum inventory requirements one neecte to characterize cumulative sales ever time rather than or in 
addition to sales per month. Extreme care neecte to be exercised in aggregating sales over consecutive months since 
these are highly correlated. Thus, a straightfonvard convolution of orders in consecutive rno^ lead to serious 
underestimates of the variability of cumulative orders and hence to the determination of inappropriately low safety 

5 stocks (minimum inventory levete), exposing the manufacturer to undesirable frequent stoctouts. These would result in 
inappropriate customer service, lossof nwM share and last but nollea^, a continuation of the vicious cydeprev^ 
Ing the manufacturer from estabfishing reliable forecasts in the first placa 

Our approach provides an exact characterization of the statisticalcfistrbution of cur^ sales based on a given 
characterization of the underiying sales pattern. 

10 The calciius used to characterize the distributtons of account orders and aggregate ord ers is t>ased on simpl e but 
rigorous probabi&ty calculus. 

The system is intuitive and fully transparent to aD users. Bekaw we give a brief outline of the inputs required by the 
system and the user interfaces which we envision developing to provide the user with various types of back^ound infor- 
mation to facOitate the task of specifying forecast inputs. 
75 The calculus used to derive all order and aggregate order distributions is explained. 

Required inputs; user interfaces 

The user wiD be responstole for ertering forecasts for spectfic account/m^ 
20 sibility For any given account/ifnodel combination, forecasts are to be provided for the next 12 months on a rolling hori- 
zon basis. The user win be confronted with a main menu pemitling a choice between: (I) whether to provide estimates 
of the accounts' sales (II) or orders (12); and (II) whether to provide estimates of monthly total sales (orders) (111) or to 
provide separate estimates (112) for 

25 (a) regular sales activities, and 
(b) Promotional activities 

We wHI strong^ encourage LAMs to opt for 

30 (l)provicfing estimates for sales, and 

(2) provicfing separate estimates for regular and promotional sales 

If option (12) is chosen, the cak:ulationsdescnl>edbek3wwOI be drcurnventeda^ orders inconsecutive 

months will be treated as independent. (This may result in inportant distortions as explained in the introduction but is 
35 unavoidabie under this option; the user cannot be expected to estirnate the interterr^^ Itiscon- 
ceivable that an 'average" correlation factor may be inferred from historical orders.) 

AU accounts managed by the three U\Ms whom we have irnerviewed folfow or wouU 
ishment policy of the following type: (a) the model's inventory p^ periodically (e.g. once a weeK once 

in two weeks, once a month); and (b) at review epochs the account places an order to increase the modeTs inventory 
40 position to a target level of a given number of weeks of future expected demancte (ag. 6 weeks. 8 weeks) unless the 
cunent inventory positfon is already abo^re this target level in which case no order i^ 

The formulae befow are based on this type of replenishrnem policy which is charact^ 
(the review period and the target ordernp to le\^ in weeks). This po5cy structure is easy to us^ 
than ortepointKrf-view. However, it wffl be easy to rrakeapproprfete modiffcationsshoukJ it become apparent that other 
45 types of replentehmentpofides are used by some accounts. 

Ir^xJts 

St= sales in period t (random variable) 

50 m= Es, . . ^ - 

W = number of periods of future demarxte to wtiich the inventory position is to be increased every tme an order is 

placed. 

The cfistribution of St is obtained by fitting an appropriate distribution to the three point information provided by the user. 
55 We fit a shifted Binomial distribution: Let 

S^n „ ironinruim sales for period t 
St"^ = maximum sales for period t 
St'^^^^most likely sales volume for period t 



47 



EP0770 967A2 

Let Si = St - St"""" and assume i, is Binomial (ap) with n = S,'™* - 81"*°^* 

[np + (1-P)1+1 =61"^. e.g. p = (s"^ -1 Vn 

5 ([x] - denotes the largest integer smaller than or equal to x) 
Outputs 

0|= order in period t 



10 



IS 



8*1 



20 



Ob = cumulative orders in periods 1 ,...,t 

IPt= irwentory position at end of period t after placing an order (==inN«nt^ 
T,= target order-up to level at end of week 

If 

25 

The following recursive relationships hold (assunrang bacWog^r^; the equations are e^ 



30 IP, = IP^,.s, + IT,-IP,.i+sJ* (1) 

o, = [T,-IPt.i+sJ* (2) 

Ot-ot-i+r,-iPM+s,i* (3) 

35 

We assume here that the St-variat)les are indeperxient of each other. 
Calculating IPt and 0| - di5trft)utions 

40 The cfislrixition of the IP, - varidWes can be conrputed recursively. Observe the IPm and s, are independent of each 
other. 

ProbnP,=T,|IP^i=I| = Prls^il-T,] (4) 

45 Hence. 

Prob[IPt»Tj =. 



(5) 

55 

For r >Tt, Prob[IPt = r I IPh = 0 = PrcblSi = I - n 
H^K^e. 
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Prob[IPt = 1'] = 

f; Prob[IP,.^^,rt=l] 'Prob[S,^l-l'] 

i^=Biax(Te-l,i 



10 



15 



20 



25 



(6) 



ProKo, = 0 1 IP^.i = I] = Prob[s, ^ I - TJ (7) 



Prob[Ot » 01 = 



(8) 



30 Calculating Cunnjlative Order D 

The dstrlxjtions of cumulative orders, Le. ttie (Ot) - distrilxition can l)e computed recursively as well but only by com- 
puting the joint cfstrixxtion of Of.^ and IP|.v 

Case 1 Let k'>k: 

35 

PrtO, = k-andlPt = TJO,.i =k,IPM =0=Prls, = k'-k + l-T,] (9a) 



PrIO»=k'andlP, = r|0,.i=KIPM=n = 0 (*) 



40 fwanr^T, 
Case2k-=k: 



Pr[Ot = k and IP^ = 1' | O^.^ = k and IP^.i = H 
\ 0, otherwise 



(10) 

50 

Thus 

PrlO^ ^k- and IP^=TJ^ Priori =KIP|.i =0. 
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Pr[s, = k^'k^l'T,] ^ £ Pr[0,.,=ic' and IP,., = 1] Pr[s,l'T,] . 

Pr [0,=ic' and IP^^l'] 

(11) 



PrIOi.i =k'andlP,.i =1]. 

Prts, = l-r] (12) 

Past PrtmKJtions Effecte Estimation 
Objective 

To assess the total inpact on sales of past promotions. 

Promotions perturb the regular pattern of sales and various types of promotional activities influence the sales vol- 
umes according to rather differert patterns. The objective of the rrio^ 
of the promotion ever time. 

Inputs 

Times series of sales. 
Tone period of the promotion. 
Class of the promotion. 
Type of the promotion. 
Intensity of the promotion. 

Outputs 

Overall impact of the promotion 
ProfQe of the impact over tima 

Algorithmic Steps 

The model is based on the use of time series models. First, an analysis is appGed to a "censorecf time series of 
sales volumes, in which all promotion (and after promotion) periods have been eliminated. One of several basic time 
series models is appfied to identify trend factors, seasonality indices and/br auto 

series models include exponential smoothing (weighted) moving averages. Winters* model. Box^enkins models. The 
following l^kx&ied Winters* Procedure uses the demand (POS or shipment) data to remove seasonafity and trend 
effects. 

Select time series model for estimation of demand for norvpromotion periocfe. 
Initial Estimation of Level Cnduding trend) at each Historical Period. 

Calculate the moving average of seasons, with each season having period P. If P is an even number, take the average 
of two consecutive moving averages to let the estimate centered on the time period. 

Estimate Seasonal Factors. 

Divide the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen the ran- 
dom rffecis by taking averages lor sirnilarperkxte in (fifferent years. Then, normalize tiie estimate seasonal factors that 
totals to P. Using the normalized seasonal factors remove the seasonality effects from thte demand data. 

Estimate Level and Trend Terms. 

Using the regression equation algaittim specified in the MDA 134 module, find the regressfon parameters for level 
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and trend coefficients to fit the regression Una Using the regression coefficients renwve the trend effects from the 
demand data. 

After an appropriate time series nriodel has been selected for all non-pronxation periods, interpolate baseline sales vol- 
umes in the promotion periods wtiich would have arisen in the sbsence of the special promotion activities. 
Calculate the ratios of the actual sales volumes du-ing the promotion periocte and the calculated l>ase line" values, for 
each promotion period separately. This defines the impact curve of the promotion. 
Aggregate the impact curves pertainirig to (Afferent promotion periocte of a given 
curve fitting techniquesw 

The resulting impact factors for each of the periods belonging to and following after a promotion interval can now 
be used in future forecasting efforts. 

Future Promotion Impact Estimation 

Objective 

To estimate the impact of a future promotion 
Inputs 

Tmne period of the promotion 
Class of the pronwlion 
Type of the promotion 
Intensity of the pronvytion 

Outputs 

Estimated overall impact of the pronvytion 
Estimated profSe of the impact ever time. 

Algorithnuc Steps 

Search promotion calencfor for past promotions with similar characteristics. 
Assess inrpact of ttie planned prornotton t>ased on computed effect of similar p^pronxytioria 
tdentrfy generic profle of promotion impact corresponcfing to the planned promotion. 
Compute estimated profile of ttie planned promotion by combining estimated total impact and generic profile. 

Analyze Promotion Effects 

This analysts includes the following three types of promotional activities: price promotions, wfiere the item price is 
recfoced by a given percentage for a limited period of time (e.g. 1 -2 weeks): promotions via feature advertisements: and 
promotions via special store displays. 

The characterization of the impact of promotional activities is to be used as the t>asis of the statistical forecasting 
procedures in the Forecasting module of our DSS 10. It wSl also k>e invoked as guicfing informatfon in the bottom-tp 
forecasting procedure. 

The sales promotfon activitfos pertufb the regular sales pattern in the commercial 
e^^ents such as scheduled eocercise in the defense application will also signfficantly change the usage of parts. There- 
fore, the models devetoped for analyzing the eftects of sales promotions will also be applicable in understanding the 
effects of the special everits in the delerise setting, fo the fbOowing sec^ 

of explanation, while the models are equally appficaUe to both the defense and commercial applications. 

It is tx3fth intuitive and extensiveiy substantiated kyy sa^eral statistical studies in the conventional marketing literature 
(see e.g., Blattberg and Naslin (1993)) that the varfous types of pronvytfonal activities influence the sales volumes 
acconfing to rather different patterns. Price promotions typically result in a significant increase in the sales volume dur- 
ing the course of the pronxstion period. The increase in ttie sales ^ume is due to: 

a. consumers irx^reasing their nomnal purchase quantities to take advantage of the temporary price discounts: 
bi consuners making a purcfiase during the promotion period who otfrenwise wouki have waited until a future point 
in time; 

c. consumers being enticed into a purchase who otherwise wouM have opted for a different t>^^ 
wouM not t)e in the market for this item. 
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Only factor (c) results in a sigrificant long term imrease of the sales voluma The first two factors (a) and (b). on the 
other hand, cause an Increase of the sales voturnediFing the pronw^ increased volume is partially or 

conpletely corrpensaled for by a dedine in sales after the promotion period. 

F^re 31 cfisplays a typical pattern for the percentage increases over time, resulting from a price promotion. As 
5 mentioned, the percentage incre^ is posrtive during the promotion period; the magnitude of the impact first inaeases 
and then deaeases. The promotk)n period may be followed 

of the decfine fret inweases and then deaeases. See Lewandowski (1 985) for more details. 

The impact of promotions via feature advertisements or special in-store displays may exhM a similar pattern (as 
in figure 18); alternatively the impact of these types of promotions may be confined to the promotion period itself. 

10 

Regression Models 

Our menu of regression equations consists of variants of the following basic equation used in Blattberg and Wis- 
niewski (1988) and with minor changes in Wittink et al. (1987). 
15 Let 



Sh = Weekly retail sales for item I at time t 
Rft = The regular (sheJf) price of item i at time t 

Pjt = The observed price (actually paid by the consumer) for item i at time t 
20 [>rt = Thedeal<fiscourtforitemlattimet((RH-Pii)/Rit). 

CPj, = The prk» of a conpetitive item j at tirne t with j not equal to i. 

Xrt = A durnmy variable whkii equals 1 if a display is run for item i at tirne t, 

Yit- A dummy variable which equals 1 if a feature ad is run for item i at timet 

Lrt = A variable representing deal decay, equaling lq-1 with j being the time since the beginning of the deal and 
25 0<k<1, 



The bask; regressfon model is: 

S^^expfai+agfl^+aaD^+LySyCP^+a^Xf^+as/^+agL^) (1) 

30 

All Off the data required for this rnodel are available in our data sources. The o^ 
bets whkrfi reflect prices charged for items provkled by competing vendors. 

able in some conwnerdal supply chain settings. If sa the item I^CPjt is efiminated from eqiation (1 ). On the other 
hand, a trend and seasonafity factors (expressed ag. via incficalor variables) may be ad^ (1). Forexam- 

35 pie, iff the year is (fivkJed into four (fislinct seasons, add the va^ 
with a trend term) to the right hand scle cl (1): 

40 Thetog-tinearfbrrnuIatk)ninequatk)ns(1)and(2)hasbeenshowntopr^ 

sin^e linear forrmiatfon. The specffk»tion in the conventfonalBI^^ model implfcrtly assumes that 

the irrpact off a prDrnotk)n is restricted to the pronrwtion period ilselff a^ 

decfines over tima To alkiw for a general palleni 0* iiTipacte as in fig^^ 

denote an upper bound on the number of periods ever whk*) a price prornotion exerciser 

45 

Uit =1 rf period t arises 1 perkxls after the beginning Off the last proiTwlion pe^ 
fc=1,K,u 
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(3) 
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The coeff rcients of the above regressfon equations will be detennined by using the generic regression routine specified 
elsewhere herein. 
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Time-Series Models 

An aftemative approach to analyze retaflerpromotk^ Rrst, an analysis 

is applied to a "censored" time series of sales volumes, in which an promotion (and after promotk)n) periods haN« 
elinwiated. One of several basic time series models is applied to Identify trend factors, seasonality indices andtor auto 
condition structures. These basic time series models indude exponential smoothing (weighted) moving averages, Win- 
tws* model, Box-Jenkins modela The following Modified Winters' Procedure uses the demand (POS or sHpment) data 
to remove seasonafity and trend effects. 

Step 1. Initial Estimation of Level finduding trend) at each Historical Period. 
Calculale the moving average of seasons, with each season having period P If P i^ 
age of two consecutive moving averages to let the estimate centered on the time period. 
Step 2. Estimate Seasonal Factors. 

Divkle the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen the ran- 
dom effects by taking averages for similar perkxJs in different years. Then, nomiafize the estimate seasonal factors 
that totals to R Usng the normafized seasonal factors renxjve the seasonality effects from the demand data 
Step 3. Estimate Le^el and Trend Terms. 

Using the regresskni equation algorithm specified elsewhere herein, find the regression parameters for level and 
trend coefficients to fit the regression Bna Using the recession coeffidenls remove the trend effects from the 
demand data. 

After an appropriate time series model has been selected for aO non-promotion periods, one can int^^ 
caOed base-line sales volumes in the promotion periods which would have arisen in the absence c* the special pnxro- 
tion activities. By calculating the ratios of the actual sales volumes during the pronrujtion periocte and the calcufated 
•base line" values, one constructs an irrpad-curve as in figure 31 for each promotion period separately. The impact 
cun^ pertaining to cfifferert pronation periods cl a given type ^ 

ard curve fitting tectwtiques, see figure 32. The resulting impact factors for each of the periods betonging to and foOow- 
ing after a promotion interval can now be used in future forecasting efforts, as guided by our l=brecasting Modula This 
approach foflows that of Abraham and Locfish (1992) who have successfuDyad^ methodotogies in their eariier 
PROMOTER system to analyze r^er promotions. The PROMOTER model has four primary steps: (1) adjustn^ent of 
the data for trend, seasonality. (2) eOmination of data points influenced by promotion. (3) extrapotetion of date points not 
influenced by promotion into promotion period, and (4) conputation cf promotion effect as the difference between this 
t>ase6ne and actual sales. 
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MODEL 


WHERE USED 


Statistical forecasting models: 

• ntoving average 

• trend 

• smoothing models 

• Holt Winters model 

• Winter's method 

• Regression based 
forecasting 

• Autoregressive / 
Moving average models 


Demand Characterization 
Bottom-up Forecast 
Top-down Forecast 
VMR 


Expert based torecasting model: 


Bottom-up Forecast 


Seasonality factors estimation 
routine 


Demand Characterization 
Bottom-up Forecast 
Top-down Forecast 
PSI 
VMR 


Forecast accxiracy routines: 

• Forecast error 
calculation 

• Exception report 
generation 


Bottom-up Forecast 
Top-down Forecast 
PSI 
VMR 


Past' promotions impact 
estimation model: 

• Regression model 

• Time series model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 


Future promotion impact 
estimation model 


Sales Promotion Analysis 
Bottora-up Forecast 
Top-down Forecast 



Table 10 
Usage of SFP Models 



Models Specific to Repair Environment 
Definitions 

Equpment consists of modules that are composed of reparable items, and repairable items are made of compo- 
nents. 

Requirement: failure of an equipment 

Conso&lalionpoficy: the porK;y of repladngtfie defective reparable module with a good reparable item 

of an already d^ective module arvi reinstalSng into the equipment 

Defective ratio: ratio of number of d^ective reparable item to the total number of reparable items in a module. 
Target level: maxirnum defective ratio acceptable before a module can be sert bac^ 
repair depot The target level is one of the two paranmtersof the ccHisolidation policy. 

Raw requirements (pre<x)nsolictetion requirements): total requirements generated by all equipment at the equipm^ 
location 

Consolidated requirements (post-consoBdalion requirements): requirements for equipment after consolidation policy is 
applied to raw equipment requirements (number of modules sent to repair depot for repair from the equipment location) 
Raw Requirements Estimation (for Bottom-up estimation) 

Ot)jective 

To estimate raw requirements for all equipment located at a particular equipment location based on the planned 
activity (usage) schedules of the equipment 
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Equipment located at the equipmertl location. 

ActMty schedules ibr ail the equpment at the equipnient location such as: 

equpment i4)gfade/maintenance schedules (preventive and breakdown maintenance schedules) 
activities ri-a, operatwn time; number 0* seti4>s. cumula^ 
planned activrly schedules to all equpffiert ai the equipment 

10 Output 

Estimations of the raw requirements to each equipmert at the equipment 



AlgorithiTBC steps 

Estatjish r^ationships between raw requirements and activities of the equipment based on analysfe of graphs, etc. 
Analyze the effects of activities on requirements using regression or time^ 

Estimate raw requirements to each equipment given the equipmenfs planned activity schedule by the models used 

abova . • x 

20 Consolidaled Requirements Estimation (to Bottom-up estimation) 

Objective 

To estimate consolidated requirements to all equipment located at an equipment to^tion based on the estimated 
25 raw requirements 



Input 

Estimated raw recpiirements to each equipment at the equipment location and the time of reqiarement 
Batching paramrter to the batching poBcy of the equipment location 
Consolidation policy (target level and the search rule) 
Inventory positions at the equipniert location to modules and reparable ite^ 

Pertomance measures: stock level, service level (availabilrty of equipment), repair cost associated with repair at 
equipment locations and the repair depot 

Output 

Estimates of consoBdated requirernerils to an equipment at an equipi^^ 
Vialues of pertomance measures 

Algormrnnc steps 

Search under consofidationpoBcy 
Identify repairable iterns to be sent to repair depot under batching policy of ^ 

Consotidalion PoUcy 

A consolidation poBcy consists of two elements: a search rule to selecti^ 
soUdated. and.a target level, that is the maximum defective ratio acceptable betoe a module can be sent back from the 
50 eauipment location to ttie repair depot. . 

Oven a newly failed module of type I with adefective reparable Item of type j. the oonsoOdabon policy drfuies which 
reparable item should be chosen out of which module to perfomi the consolklat^ 
already be part of a module with at least one defective reparable Item but containing a good conpo^ 
seaich rule select the reparable item for consoOdalion among all such defective modules. The following search rules are 

""^f out the search fa defedive modules of type I only. Sort the defective modules of type lln decreasing order 
of thedefecBve ratio and starting from the fop of the list select the first module that has agood com^ 
exists. If not sort all the other defective modules in deaeasing order of the defective ratio and startng from the 1^ 
the Dst. select thefirst module that has a good reparable item j In it if one exists. If not. (consolidation cannot take place) 
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replace the failed mcxiule I with a good one. if one is available at the equipment location. H not, equipment becomes 
unavailat)le untfl either a consolidation or a replacement can be mada 

Determine an module types for which stocks of good items at the equipment location are below a threshold value. 
Sort ttie defective modules of all such types in decreasing order of the defective ratio arxl starting from the top of the 
list select the first module that has a good reparable item j. if one exists. If not sort all the other defective modules in 
decreeing order of the defective ratio and starting from the top of the list, select the first module that has a ^x)d repa- 
rable item j, if one exists. If not (consoBdalion cannot take place) replace t^^ 

of type I, if a good one is available at the equipment kx:ation. If not the equipment becomes unbailable until either a 
consolidation or a replacement can be mada 

Sort the defective modules of all types in deaeasing order of the defective ratio and starting from the top of ttte list, 
select the first module that has a good reparable item j in it if one exists. If not (consolk^^ 
the ^led module of type I with a good one. if one is available at the equipment location. H not equipment becomes una- 
vailable until either a consolidation or a replacement can be mada 

Batching Policy 

The batching poBcy is defined by the size of a batch. TH1. (TH1 can be equal to 1). The inventory poOcy is in the 
fomi of: count the number of defective modules with defective ratio y eater than the targ^ level. H this number is greater 
than TH1. then send TH1 units of repairable iterns to the repair shop else wait untfl this condition is satis^ 

Consolidated Requirements Estimation (fa Tofxiown estimation) 

Objective 

To estimate consdidaled requirements for all equipment located at a particular equipment location based on his- 
torical data 

Irput 

Trme series of consofidated requirements for each equipment locations. 
Output 

Estimates of consoKdated requirements for aD equipment at an equipment k>cation 
Algorithrrac steps 

Use a conventfonalKalnfianfflter based algorithm and cofi^^ con- 
solidated requirement for the equipment 

Determining a repair plan 

Objective 

To determine a repair plan based on aggregate repair plan, and repair constraints (resource capacities and key 
componerrt avaflability) 

Input 

Aggregate repair plan 

Available resource capacities and degree of f lexUity to change resource capacities 

Key component availabnity (projected inventory positions, sufiplier arvl lead time information, inventory replenish- 
ment policy) 

Output 

Repair plan for the repair shop that b feasflDle with respect to the repair constraints (capacity and key corrponent 
avaflatMlrty). 
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Finished Goods Inventory Management (FGIM) 164 
Scope and objective 

5 Objective: Decide where to stocK how much and when to replen^ in (hybrid) made-to^stock/imade-tOK>rder envi- 
ronment. 

Scope: Single and dual echelon. 
Features: 

Single and dual echelon inventory models for how much and when to replenish stocking points. Cost vSw service trade 
10 offs to detennine where to stock. 
Deptoymerrt 

Models specific to manufacturing environment 
Overview 

15 

Objectives 

This module contains a collection of finished goods* inventory models enabling the selection and evaluation of 
inventory policies. The module returns an \- and P- line extended to a given horizon (of T periods) beyond the current 
20 period. At this stage, all of the models represent setting where any given item is distrSxjted to the customers from a 
single kx»tion. 

Input 

25 Forecasts of mean demancte per item, per period (S* line) : standard deviations of demands per period per item (a* 
line); mean production lead times for each period per item (L line): standard deviations of lead times for each period, 
per item (t' line). 

Output 

30 

Inventory (I) line 
Production (PO line 
Ins^entory strategies 

Models are dassffied as follows: Ml. Models wHh Non-Lumpy Demand; and Mil. Models with Lximpy Demand. Uffnpy 
35 demands refers to s^'ngs where demands are sporadic or experience extreme variability The demand process for a 

given item wfll be dassmed as lumpy if the percentage of zero demand periods or the coeffident of variation of the 

demarvte is atxive pre^spedfied critical levels. 

Within the category Ml we next cfifferentiate between: MI.1 Models managing inventories or on an item^iy-item 

t>asis; and M 1.2 Multi-item nxxfels with jdnt cap^aty corYStraintSw 
40 The Choice between these two categories deperxJs on whether or not irnport^ 

theiten^Onthefonrnof jdnt capacAy constraints or joint cost stnjct^ MI.1 and 

M L2, dHferent models can be selected based on the extent to which policy parameters are to be pr&«pedf ied by the 

user or confuted based on an appropriate tradeoff between cost and senoce nrieasures. 

45 Ml liwentory Models for f^torv-LiOTYiy Demand 

MI.1 Modds for Independent Items 

As mentioned above, in this category inventories are managed on an item-by-item bads. Different nxxiels need to 
50 be invoked dependent upon the extent to which pdicy parameters are to be specified by the user. Atternatrvely. the 
models to be used can be determined endogenoudy based on an appropriate tradeoff analysis or optimization of vari- 
ous cost arxi service measures. 

Ml.1.1 User-Spedfied Base-Stock Polides 

55 

Objective 

In this modd. theuserspedfiesanorder-up-toorbase-stocklevdasagivennunfiberof weeks of invent^ Based 
on this inventory policy, the modd projects out an r and P* One for a scenario in which the forecasted mean demands 
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are realized. 

Adcfitional Inputs 

The desired base-stock let^ for each period 

Rt = nurT4)er of periods of future forecasted (temands in 
ning of period trfl)ek3w 

Algorithm 

Step 1: Compute l>i = S, + 8^.1 +...+ S^. (H Ht isspedfied as a fractional value, bx equals: 

bt = S, + St^i+...+ SLrtj + (n, - LnJ Sprtri) 
Step 2: Project r and P lina l^: 

lb = inventory position Onventory level plus outslantfing orders) before ordering at beginning of period 1. 
P, = production volume ordered at beginning of period t. 

Set Pi = bi - lo; project recursively for t = 1 .....T-l : 

l»^i=max(bt,lt) + Pt-S, 
Pt^i=max(b|^.i-ln.i ;0) 

Step 3: Evaluation of various service and cost measures. 

a) ag.. expected average inventory level, 

b) probability of stock-out 

c) f9l rate or percentage of demands satisTied from stocK 

d) nurrter of setups, 

e) average backtog sizes. 

MI.1 .2 MIN-MAX PoBdes Based on Optimization of Aggregate Cost Measures 
Otsjective 

In this model, a policy is computed which minimizes the expected value of the aggregate of all relevant cost com- 
ponents, i.e. l)s^ costs; 2) inventory carrying a)6ls; and 3) backlogging costs. The rnode! is appr^^ 
where stock-outs are fuOy backtogged and where the inventory carrying and backlog 
inventory levels arxj backfog sizes. 

Adcfitional inputs: 

Hokfing cost rates per item per period (h* fine) 
Backfo^ing cost rate per items per period (pMine) 
Variable production cost rale per item per period (c* tine) 

Algorithm 

Step 1: Load S' (Sales), & (Standard deviation), L (Lead times). V (Standard deviations of lead times). IC (setup 
costs), h* (Holding cost rates), p* (baddogging cost rates), c* (variable productfon cost rates); 
Step 2: Fit appropriate demand dislnlxjtfon to S*. & Bnes. 
Rt appropriate lead time cfistributions to L' and lines. 

Step 3: Solve for timeiJhased optinial (s,Q) policy. Such a policy has for each period 

and Qi such ttwt whenever beginning inventory positfon IfCSt an order is placed for (SftQi - IJ units. Parameters (St, 

QO are computed from the toltawing recursfon. 

Let 

V,(l) = expected nwiimum coste in periods 1 1+1 T given that period t starts with an inventory position of I 

units. 
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Gfy) = expected (inventory carrying and backtogging) costs associated with period t CTWs function uses the 
lead tinrie and demand distributions computed in Step 2 as well as th^ h'andp' lines.) 
D, = demand in period t 

5 Solve: 

10 

htote: the user is provided wflh the option to specify ranges for the produ ranges 
may r^lect capacity limits per item, or f lexSMlity limits in view of prior determined P and 1' lines. The ranges will be 
used to restrict the choice of X . 
Output: 
15 Forallt = 1.- -.T; 

xt*(l) = optimal order quantity at the beginning of period t when inventory position = I. 
Step 4: Create r and P* lines. 

20 h is known; se* = production lot initiated in period 1 equal to X*i (0- Then project recursively for t = 1 T 

lt+i = k + x*t{IO-S, 

25 Step 5: Evaluationof various cost and servk;e measures, as in Step 2 of model M1.1. 
MI.1 .3 Periocfic Review Models Under Service Level 
Constraints 

30 

Ok)jective 

In this category of models the inventory poficy minimizes expected setup and holding costs subject to user speci- 
fied sennce level constraints. The user may choose between the two types of conventional service measures. 

35 

Type 1 Servk:e Constraints: 

Maximum pemvtted probabOity of a stock-out during lead-time foltowing potential order at t>eginning of a given 
period. Let: 

40 op maximum pemvtted Bkelihood of stock-out c&iring lead^'me folkiwing potential order at beginning of period 

t 

Type 2 Servk;e Constraints: 

Minimum acceptable fin rate during lead time folk)wing a potential order at beginning of period. Rl rate is defined 
45 as the percentage of demarxl satisfied from Stock. 
Let 

Pp minimum ^xeptable ffll rate during lead time foltowing a potential order at beginning of period i 

so The model is based on the same assunptkxis as MI.1 except that stocknput frequencies are controlled via service 
level constraints (of Type 1 or Type 2) as opposed to explicit stockK)ut or b^ 

Adcfitional Inputs 

55 holding cost rates per item per period (h* line) 

maxinwm permitted stock-out probabflities per item per period (a* line), or nrtinimum acceptable fill rates per item 
per paiod (p* Bne) 
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Algorithm 

Step 1 : Load S' (Sales). <f (standard deviations). L Oead-tlmes). K* (setup costs), (holding cost rates). € (variable 

production cost rales), a (service level type 1) or p (service level type 2). (Lead-times are specified either as con- 

^ants a via ranges with associated likeOhood for each value in the ranga) 

Step 2: Frt appropriate demand disln*l)utk>n to S', a* fines. Determine lead time demand distractions. 

Let: 

LDt = lead time demand for order placed at l)eginning off period t If lead time demand dislrftxjtion is chosen to 
t)e Normal (for exarrple). then set its mean and variance as follows: 



i-i 



Step 3: Compute nrinimum inventory positions after ordering St , via Reorder Point Algorithm. t>elow: 

Step 4: Solve for time-phased optimal (s.Q) poficy. 

Let: 

V, (0 = expected minimum costs in periods t. If 1 T given that perfod t starts with an inventory position off I 

units. 

Gi(y) = expected inventory carrying and bacMogging costs associated with period t 
Dt = demand in period t 

Solve: 

t = 1, - - . ,T; all I 



Output: 

fora!lt=1.-.T; 

x*t (0 = optimal order quantity at the beginning off period t, when inventory position = I. 

: the user is provided with the option to specify ranges tor t^ 
may refftecl capacity Bmits per item, or flexa)ifity Bmits in view off prior drtenmined P and r lines. The ranges will be 
used to restrict the choice of X in ^). 
Step4: Create r and P Ones. 

h is known; set Pi = production lot initiated in period 1 equal to x*i (I). Then project recursively for t = 1.....T 
k.i = tt + x*,(lt)-S, 

Step 5: Evaluation off various cost and service measures, as in Step 2 of model M 1 . 1 . 
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10 



IS 



MI.2 MuW-ten C^)acilated Perkxfic Review Models wHh Service Level Constraints 
Objective 

This category of modete plans simultaneously for a complete family of items incorporating various joint capacity 
constraints. The model plans production quantities on the basis of estimated mean demands; however, minimum inven- 
tory levels are specified to satisfy user specified service constraints (of Ty^ 

r line are in this case delemiined by the solution of an LP-model. The user specffies whether minimum inventory levels 
are to l>edetenrtned on the t)asis of Type 1 or Type 2 constraints. In addition, the user chooses among a nuntoer of 
possit3le objective functions (performance me^ures) to select among feasa)le plans. 

LP formulation 

Model: 

LP formulation for I products (or product group) K resources (Key Component and/or Unes) sets and T periods 
Input 

20 Sh = Demand for product! at period t 

Si, = Mintnum anrK>um of prockK:! i at the end of period t 

Ijo = Initial inventory of product i at the Ijeginning of the planning horizon 

ami = Units of resource m. among resources in set Sk. reqiired per unit produclion/irepair of product i 
Cmt = Units d resource m which t)ecomes availal)le at period t (In case re^ 
25 amoum of it availak)le a* the l)eginning of the horizon under consideration.) 

Decision N^riatiles: 

Pit » Units of product i to produce in period t 
30 Xmit= Units Of product i to produce in period fusing resource m in Sk 
la = Inventory of product i at the end of period t U» (A) Optimize: 
CVl , 0V2, 0V3 or OV4 specified below: 
sut)jectto 

^ Iu.i+Pu-Sit=Ii. for i = 1,2 I and t = 1,2 T (1) 

^in sAit^Pit: ^ = K, i=l,2 I and 

t = 1,2, , . . ,T (2) 

E-oto J^i 5UX^<=J:.-o tocC« for each key component m and 



40 



45 



50 



t = 1,2. . ,T (2.1) 
E a^x^j.<=Co«, for each line resource m and 

t « 1,2, . . .,T' (2.2) 

I,^i8,t for i=l,2 I and t = 1,2 T (3) 

x^^iO for m in Sjt. k=l,2,...,K, i=l, 2, . . . , I and 

t = 1,2, ...,T (4) 



Constraints: 

calculate the inventory levels, 
55 (2.1) and (2.2) ensure that consumption does not exceed resource avaOability, 

ensure inventory is no less ttian pre-spedfied levels and ensure that production/irepair is non-negative. 
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Output: 

Feasibaity of LP 

5 H yes, a production plan : Pftfor i = 1.2.....I and t = 1,2,...J the corresponding inventory levels : Iftfor i = 1,2,....l and 
t = 1 Z....T and remaining resources : slacks in (2.1) and (2.2). 

K no, cfisplay sources of infe^dxlrty : surpluses in (2.1) and (2.2). 

0V1 : Maximize maximum slack in resource constraints (2.1) and (2.2) 
10 0V2: (Balance Workload). 

'T»ni:[amiXmi/Cnrt] 

0V3: Minimize variat)le production and holding costs 
minJ:[q,Pii + hitliJ 

0V4: Minimize maxirmm inventory in weeks 
IS minmaXit[lrt/Si,] 

Algorittim 

Step 1 : Load S' (sales). & (standard deviations), L (lead times), (hokfing cost rates), C (variable production cost 
20 rates), V (standard deviations of lead times); resource utaizatkm matrix [a^ capacity levels [C^. 
Step 2: Determine lead time distributions LD,, as in Step 2 of MI.1 .3. 

Step 3: Compute rrenimum inventory positions after ordering Si ,"\st via Reorder Point Algoritftm. 

Step 4: Solve above LP 

Steps: kienticaltoStepSofmodel Mll.l. 

25 

M II. Inventory Models for Luirpy Demand 

Apply to lunpy demand. The lumptness of demand is measured as proposed herein. 
30 M 3.1 Maximum Demand during Period W Policy 
Ot)jective 

This policy is suitable lor k3w cost sk3w moving items with lumpy demand. 

35 

Inputs 

S* line, cover period n. 

40 Outputs 

MAX level, inventory target 
Rames using these models include 
PSI Planning Frame 160 (CF^) 
45 VMR Frame 250 (CF19 and era)) 

Algorithm 

Step 1. Use rrtethod 1 to categorize lumpy demand 
50 Step 2. Detennine a worst case scenario woukJ be to set *n' as ttie replen^ment lead-time. 

Step 3. Detemrane the maxirraim demand diring period W and set it as the inverrtory target, MAX. 

Step 4. Ckmipute r line: 

Iji-i+xit^ = ^for j = IZ . J and t = 1,2,...T 

55 M 3.2 Expected Deficit MIN-MAX 

Objective 

This policy is suitable in cases wh^e ttiere are fairty expensive items that have lumpy demarxj. 
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Inputs 
S* line 

5 Outputs 

Max level, inventory target 
Frame using ttie model includes 
PSI Planning Frame 160 

10 

Algorithm 

Step 1. Use method 2 to categorize lumpy demand 

Step 2. D^ne expected d^idt due to lumpiness as average amount that the quantity on hand is likely to fall before 
75 a replenishment order is placed. 

Step 3. Approximale the expected deficft (average period sales) as one-haH of the beginning and encfing quantity 
on hand between quantity-on-hand record updates. 

Step 4. Set ROP as safety stock plus demand during the lead-time and expected deffcit. 
Step 5. Set the MAX level as the ROP quantity plus the order quantity less the expected deficit. 
20 Step 6. When the inventory level reaches the reorder point the difference between the targeted quantity MAX and 
the quantity-on-hand is ordered. 
Compute the r line: 

^i+Xjr<Jji = Ijt for j = 1 ,2,...,J and t = 1 



MODEL 


WHERE USED 


Inventory models tor independent 
items with non- lumpy demsmd: 

• User specified base-stock 
policies 

• Min-max policies based on 
optimization of aggregate 
cost measures 

• Periodic review models 
under service level 
constraints 


PSI Plsmning 
VMR 


Inventory models tor miuiti-item with 
non-lunqpy demand: 

• Capacitated periodic review 

model with service level 

constraints 


PSI Planning 


Inventory models tor lumpy demand 

• Meucimum demand during 
period *n' policy 

• Expected deficit min-max 
policy 


PSI Planning 



45 

Table 11 
Usage of FGIM Models 



50 

Models specif ic to repair environment 
Determining CSI levels 

55 

Otsjective 

To detenrone CSI level for each module typa 
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Input 

repair shop repair time estimates 

consolidated requirements for equipment for the previous periods 

5 

Output 

CSI levels for each repairat)le item type 
10 Algorithm step 

For eadi repairable item, set CSI level to CS\^^ cakaiate the corresponding perftxmance measures. Based on 
valuesof the perfomiance measures and the estimated consolidated requirements, change the CSI level and repeat 

Performance measures that can t>e considered for determining the CSI level for each repairable item are the total 
IS cost of repair (setip cost + repair cost), and the fill rate (service leveQ at the repair shop. 

CSI level for each repairable item must be grater than or equal to the value of CSUn. which is simply the sum of 
the requirements during repair time arxJ a safety stode CSI^in ^ ^requirements over all equipment locations during 
repair time of one unit) + safety stock where safety stock is a user defined parameter, based on past requirements. 

20 Deterniining aggregate repair resource requirenrients 

Ot)jective 

This process includes the ot^eclives: (i). to estimate number of consolidated requirements for equipment triggering 
25 repair at the repair shop; (iO- SPven (i), to estimate number of repairable items requiring repair at the repair shop; and 
(Si), given (n), to estimate aggregate repair requirenr^ents at the repair shop 

Input 

30 CSMevels 

consolidation poGqr target level 

Types and nunbers of repairable items in each equipment 

BOM for each repairable item (to go to the component level) 

Fmal estimations of consolidated requirements for the equipment 
35 Fmal estimated repairable item requirements coresponding to the consolidated requirements for equipment 

Repair dala for each repair*le item (operation sequence and repair time estimates for each operation) 

Output 

40 Aggregate repair requirements ^tf^ repair shop 
Algorithmic steps 

Estimate number of consolidated requirements for equipment triggering repair at the repair shop 
45 Estimate nuriiber of repairable itenre requiring repair at the repair shop 
Estimate aggregate repair requirements at ttie repair sfK)p 
Generation of a feasible aggre^te repair plan 

Objective 

50 

To generate an aggregate repair plan based on aggregate repair requirements, and repair constraints (resource 
capacities and key component availat>ility). 

Input 

55 

Aggregate repair requirements 

Avaitat)le resource capacities and degree of f lexitMlity to change resource capacities 

Key component availabflity (projected inventory positions, supplier and lead tin^e information, inventory replenish- 
ment policy) 
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BOM for each repairable item family (to go to the component leveQ 
Output 

Aggregate repair plan for the repair shop that is feasftjle with respect to the repair constraints (capacity and key 
component avaflabilit^ 

Algonthmlc Steps: 

Check if aggregate repair requirements are feasWe with respect to capacity constraints of the resources 
H not change capacity of flexiljle resources. If ^11 infeasflale. point out inffeasil)ility and go back and move aggre- 
gate repair requirements forward or backward in time 

Determine key component requirements and time of requirement from aggregate repair requirements 

Check if aggregate repair requirements are feasible with respect to key conr^ponent availabiBty constraints 

tf not point out infeasftMlity in terms of component availability. Change key conponentavaila^ 

equpnent based on the fHirchasing polides for the components. If stfll infeasiWe, go back and move agg^egate repair 

requirements fonvard or backward in time until afeasible repair plan is generated 

Aggregate Production Planning (APP) 162 

The Aggregation Production Module 162 focuses on its PSI Frame 160 applicatton. The following two capacity 
checking models are identified and devetoped to support the Model Engine 20 requirements in the PSI Frame 160. 

Objective and Scope 

Objective: Fadlitate the master production scheduling process. 
Scope: Rnished goods production in some aggregate view. 

Features: Rougtwait capacity checking for ftehed goods; Major components (feeder plante) represented in con- 
straints; and Ability to identify vfolated constraints. 

Capacity Checking Models 

In the Capacity Checking models, the problem of checking whether there is enough resources to satisfy require- 
ments is formulated as Unear Progranrining Problems. These models are applicable to both the manufacturing and 
repairing environment in the PSI frame. The capacity checking models are presented in manufacturing temre these 
models also apply to the repair environment and are used in the cortext of the Req^iirement-Swly RecondHation 
frame to assess the feasibiGty of a repair plan. 

Sales and safety stock sanity check 

Objective 

Check whether there is a feasible production plan to satisfy given sales and safe^ 
Input 

I = The number of products to be considered. 

K = The number of resources (productfon Ones and key components) sets. 

Sk - Ttte set of resources. 

T = The planrting horizon. 

Sh = Demand for product I at period t. 

ISSit Safety stock of product I at the end of period t 

Ijo = Initial inventory of product I at the beginning of the planning horizon. 

ami = of resource m. among resources in set S^, required per unit production of product I. 

Cmt = Units of resoirce m which becomes available at period t (In case resource m is a key 

amourrt of it available at the t>eginning of the horizon under consideration.) 
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Output 

FeasibflityofLP 

5 Hyes, 

a production pto: 

Pijfori=1^ land1=1^,...J 

the corresponding inventory levels: 

lijfori = 1^...Jandt=1.2 T 

10 and remaining resources (slacks in consbainis (3) and (4)): .^^k^^ 

S..c™X<,».,^ia™ix„*fcrea*teycoa^mandt = 1.2 T and c^-i:,a^„ for each producbonhne 

m and t = 1 ^.....T. 

H no. display sources of infeastoiTity (surpluses in constraint (3) and (4)}. ...^r^ 

I^..TXps„i,-r^.„.c™for each toy con^m T and L^a^^-c^ tor each producdonSne 

15 mandt= 1,2,...T. 

Linear Programrang Formulation 
Dedston Variables: 

20 

Prt= Units of product I to produce at period t 

Xmit = Ur«ts of product I to produce at period t using resource m in set Sk» 

dit^Demand for product I during trie periodt 
lit = Inventory of product I at trie end of period t 

25 

Objective fuTKlions: 

Mirinize maximum procfciction line utilization (smootti production line utilization): 
Miramize z 

30 subject to L I a,™Xriri^<=z«or each Bne resource m^ 

Minimize maximum inventory level: 

Minimize z subject to lft<=z fori = 1,2 Iandt=l,2 T. 

Mirtimize total inventory le«l: 

Minimize T^T^h 
35 Mininnze total inventory cost 

Minimize EiEtChftlit** Pit Ht ) . . « n- 

subject to H, = la*- k\ li,*>= 0 and Ij,- >=0 for I = 1 ^ I and t = 1.2....,T 

wTiere r\t = cost per unit rwkfing and 

40 Pit = cost per unit backlog of product I at trie end Of period! 
Constraints 

Inventory balance formula 

45 

lrt-i+Ptf4t=>ft fc^ ' = 1 ^ ^ * = T. 

Resource aflocatlon 

EminSkX„ni=Pitforlc=1Z-..Kandt=1,2 T 

Key component availability 
50 i:^tDt5^iamP^<=JWototCn«foreachkBycomponertmandt 

Production line capacity 

J^iamPW^Cmtfo^eacfi production Bnemandt = 1.2 T. 

Safety stock requirement 

lit>=ISSi, for i= 1 ^.....1 and t = 1 ,2 T. 

55 Non-negative resource allocation 

Xmrt>=Oformin Sk. 1.2...., K, i = 1,2....,l andt = 1^.....T 
Capacity CTiecking Model ^ 
CCM1 : Lteer selected objective function sul^ect to the above constraints. 
Rames using thfe model include PSI planning (CF13), VMR. (CF 20) 
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This LP formulation, wrth minor changes, is also applicable to a repair environment where reparable items corre- 
spond to producte, repair requirements for reparable items correspond to demancte for products, and broken reparable 
itenrs awaiting repair at the repair shop correspond to key components. 

For the repair environntent. key component availabifity constraint (the fourth constraint) should be modified as in 
5 the following to represent broken reparable item availability at the repair shop : 
4) Broken reparable item availabQity: 

5^ to 1 2^ m xmfe<= ^ to t Cte for each repairable item i and t = 1 ,2... a 

Objective functions and the other constraints in a repair environment wiO be similar to those of a production envi- 
rorvnent, which are given above. The LP model for the repair environment win either produce a capacity fe^S}le aggre- 
10 gate repair plan that satisfies the repair requirements generated by reparable item failures or display sources of 
infeasA)ilrty. 

Productfon requirement feasibility check 
75 Ok>jective 

Check whether a given production plan is feasible with respect to aggregate production capacity and key compo- 
nent availakMGty. 

20 Input 

I = The number of products to be considered. 

K = The number of resources (procfoction lines and key components) sets. 
Sk = The set of resources. 
5S T = The planning horizon. 

PjP Units of product! to produce at period! 

a^i = Units of resource m, among resources in set S^, required per unit production of product i. 

Cnrt = Units of resource mwhfohbeconies available at period t. (In case resource mis a key component. Cmo»s the 

anriount Gf it availabte at the beginning of the horizon und& consideratiOT^^ 

30 

Output 

FeasS)ilrtyof LP 

35 If yes. display remaining resources (slacks in constraints (3) and (4)): 

2:8=0tot<W-i^totEtamP^is for each key componertmandt=1^ line 
mandt = 1.2....,T. 

H na dteplay sources of infeasfoility (surpluses in constraint (3) and (4)): 

J^tot2:ia„riX^-Es-0totCms for each key component mandt= 1.2 T and Lia^pc^-Cnrt for each production line 

40 mandt = 1Z-",T. 

Linear Programming Formulation 

Dedsfon Variables 

45 

Xnrit = LJnits Of product I to produce at period t using resource m in set Sk- 
Capacity Checking Model 
so CCM2: Objective functk)n1)sul3ject to constraints 2). 3). 4) and 6). 
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MODEIi 


WHERE USED 


Capacity checking models: 

Sales and safety stock sanity check 

Production requirement feasibility 
check 


PSI Plcuming 
VMR 



Table 12 
Usage of APP Models 



15 

Vendor Mareged Replenishment (VMR) 252 



Overview 

20 This section describes the spedficalions of the various models used In the VMR modules. The description is 
cfivided into three main categories: (1) Inventory Requirements Selling Models, p) Strategic Models, and (3) Opera- 
tional Models. The notation tor these nxxiels Is Introduced as necessary throughout this section. 

The models developed in this section are based on prior results In the professional literature as wefl as from other 

sources. 

2S 

Scope and objective 

Objective: Analyze contractual agreements with customers; and Decide on what to ship, in wrhat quantities and 
when. 

30 Scope: Selected products for selected customers. 
Features: 

Evaluate poBcy param^ers such as bounds on customer Inventories, target service level and delivery frequenaes. Sta- 
tistical forecast ol retailers* sales (i e. forecast of sales of PCEC's customers to their customers). Detemnine shipment 
rec^remerrts and delivery schedules. 
35 Inventory Positioning: The Multi-Item, Two Echelon Model 

Overview 

This section presents two models; the first model describes an algorithm for the calculalion of required echelon 
40 lriventories.(Echeton inventory == inventory in transit from the plart 

In transit from the DC to the stores + Inventory on hand at the stores.) The second model estimates the expected level 
of service provided at a certain D.C, given a delivery quantity. Two iriiportart 

escpected value and standard deviation of the lead-time demand- These models compute the stock-out probabflity of 
toda/s delivery on the day of its arrival to the stores. This is based on the approKinr^^ 
45 prior research on the Mulli-ltenrKTwo-Echetonproduclion/^^ 

Objective 

This moAiIe confutes the required echelon Inventory levels (R' line) at the beginning o# each review period over 
50 the wrtwie planning horizon. Clearty, these requirements depend on the delivery frequency used (the requirements 
increase as the delivery becomes less frequent). Ttujs, the required inventory levete (R* Gne) are calculated separately 
for each one of the pre-specif led delivery frequencies. 



Input 



55 



Network structure. 

Demand forecast (m^ns. standard deviations and Aspersion factor). 
Required service levete 0" terms of slock-out probability). 
Set of possOile delivery frequencies. 
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Lead-times from each plant to eray DC it replenfehes, and the average l^times from every DC to the stores it 
sigspGes. 

Planning horizon specifications 

5 Output 

Required inventory lines (R* lines). 

Notation 

to - t)eginning period of the planning horizon (assuming that today* is the l>eginning of period number 1). 
T - the length of the planning horizon. 

R'Ki j) - required inventory level, of product j at DC I. at the t>eginning of period t when delivery frequency f is 
appOed. 

os - required service level lor product j at DC t. 
^^ • mean demand for product j at DC I during period L 

- standard devialfon of the denriand for product j at DC I during period t. 
b\ - demand cfispersion rate for product j at DC I. The dispersion rate is def ined as follows: 

■ restores (i) 



and is assumed to be constant over time, stores (I) denotes the set of stores replenished kiy DC I. Note that we do 
25 not require the data o^^r which represents standard deviation of demands at individual stores. The parameters b\{s 
can be calculated (or even roughly estimated) liy an observation of a set of historical stores* data. 
^ - Lead-time from the plam that produces product j to DC I. 
X| - Average lead-time from DC L to its storeSp for product j. 

Q- Set of 'quarters' into which the planning horizon is spnt Each quarter is a contirnjous time interval consisting of 

30 one or more periods. 

Qo, - CXiarter nunnber q and the nurrber of periods in it (note thai 

F- The s^ of aDpossilJIedeBvery frequencies. Each delivery frequency! is specified as th number of peri- 

ods between tsw consecutive defivery periods. The values f must be integral (for non-integral values, redefine the 
base period. e.g. half a week instead of a weel^. 
35 |iWm), o*i(m) - The mean and standard deviation of the demand for pi-oduct j at all stores swlied by DC I, over 
periods t untfl t^^^-l^ (m^ is a pararneter of these fui^^ 
whk;h a delivery shi)ped from the plart at period tHn (next possit)le ^ 

Algoritfim Steps 

For all product-DC couples fi^D 
For aD frequencies f in F 
time 1= 0 

For aB %{iarters* q in Q 
45 For aB periods! = 1 to X^Sq! 
tvne := time + 1 

// ocnrpute the time to next feasft)le defivery period, 
tjdel.// 

t_(tei:=f-I(t + f-1)modf] 
50 tlme_to_DC := t_del + Ljj 

timeJojBtores := time_to_DC + ly 
compute the values 



55 
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(R.2) 



(t dei) = 



10 



15 



cUld 

(R.3) 



olj(tjdel) = 



Ibr a part Of a period use the following imerpol^^ be the fraction 

of that period. Then, 
20 (R.4)mean = a 

(R.5) std = 

25 

Use (R.5) if the demand in this part of the period is assumed to be independent of the demand during the rest of the 
period. Another way to calculate the standard delation can be. for instance. 

The inventory requirement for perkxJ time is new computed via 

35 {R.6) 

U.j) ={lif ( tjdel ) ( 1 -ttiP d -.^f^ ( t_del ) 

40 End For (t) 
EndFor(q) 
EndF=6r(f) 
EndFbrfij) 

Estimate 8tockK>ut Probability for a Given Replenishment 
45 Quantity: Model (OR1): 

Objective 

For a given replenishment quantity of product j, delivered from plant p(j) to DC I. this model estimates the expected 
50 projected stock-out probability The stock-out probatrility is defined as the probability of shortage in at least one of the 
stores replenished by the DC The word "projected" refers to lead-time periods later, when goods are expected to reach 
the stores. 

Notation 

55 

In addition to the rotation defined up to ttiis point, we define: 

DEUV - delivery siza 
date - date of delivery. 
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an- - (expected) arrival date of goods to stores 

Xy^*- the echelon inventory level of product] in EX) I, at (period) time data 
Algorithm Steps 

5 

Use formula (R5), with t_de!=1, to calculate the expected demand over the lead-time. 

10 

(1). Scmilarty calculate the standard deviation of this demand, 

ddace 
ij 

IS 

(1), via formula (R.3) {a^, by setting t_del=1). 

The projected stock-out probat)ifity can be approximated by: 

(OR.l) 

.... J xf?'^^DELIV-^1^'^n) 



^ In certain Situations the user may be interested in toKwingth^ 

interest may arise when no deliveries are planned for subsequent (number of) period(s). To evaluate the prpiected 
stock-Kxrt probability at period arr+k, when no deliveries are to be made during the following k penods (i.e- dat&^-l , .... 
dat&f4^p use the fonrrula: 

30 

(OR. 2) 



35 



strategic Model: VMR Contract ® 
40 Ot)jective 

This module consists of a set of rnodelstaitored to support replenishme^ (1) service level 

requirements: (2) linits on customers' inventory investments; (3) transportation costs; and (4) delivery frequency. 

45 Input 

Betow is the input which is common to aU of the models described in this pa^ 

Network Structure. 
Demand Forecast 

50 Lead^imes from each Plant to each DC and (an averse) from each DC to Hs Stores. 

Planning Horizon Spectficattons 

Current Inventory Positions, 

Transportation Cost Structure and Trucks Volumes. 

Products' Vblumes (for Transportation Cost Cakajlations). 
55 Coning The Optimal Delivery Frequencies: Model (CI ) 

Objective 

Thfe model confutes delivery frequencies from each plant to the DC it replenishes such as to minimize total trans- 
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portation costs. The delivery frequencies are set such that given requirements on service lev^ are satisfied and such 
that constraints on average inventories are not violated. 

Input: 

Inventory Requirements (R* Line, see Model R). 

Set of PossUe Defivery Frequencies, 

Required Sennce Levels On Terms of Stock-out ProbatMGties), 

Uirits on Maximal Inventory Investments (in terms of Weeks of Demand). 

Output 

Delivery Frequencies. 
Estimated Level of Sennce. 
Estimated Transportatk)n Costs. 
Eslinstsd Inventory Levels. 

Notatkxi 

We use the same nolatton as in Model R (except for the notatkMi for delivery frequencies) plus the foflowing: 
Indices 

i - DC index 

j - product (module) index 

p - plant index 

f - defivery frequency index 

s - index of fine segment of transportation cost function (the cost stnjclure is approximated tsy a piece-wise linear 

fUKtion) 

t- time index 

q - quarter index 0 

Sets 

l-setofaODCs 
J -set of all products 
P-se^ of all plants 

F - set of possisle delivery frequencies 

J^-aDpcoductssoUtoDC i. 

Jp - all products produced in plant p. 

Transportation cost parameters (for deliveries from plant p to DC i) 

volip - total volume of a single truck 

c^ - cost of fun truck toad (FTL) 

fix^ - fixed cost of less than full truck toad (LTL) 

- (righ9 end point of the s-th line segment (i.a. . ip.s] ) of the LTL cost functton. 
ratSp^ - transportation cost rate for volumes in segment s 0-e.. in t)etw«en Xp^i and x^^, ft)r LTL shipments. 
Vj - volume of product j (for cost cakaiaiton purpose) - upper Omit on the average n^ 

OC i in quarter q. 
Decision variatsles 

X*ij - echelon inventory of product j at DC I (including outstanding orders) in the t>eginning of period t. 
S\ - defivery quantity of product j to DC I in period t. 

F*C - an indicala set to 1 if in quarter q a delivery frequency f fe ft)flowed for the replenishment of DC I by plant p. 
Otherwise it is set to zero. 

NFT^ip - nurnber of full^mck-toad sent to DC I from plart p during pertod t. 

LTL^ip - volume of LTL (zero if none) shipment sent to DC I from plant p during period L 
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Y*^B - total volume of LTL shipment that falte into line segment (cost rate category) numbers. Note that . 
Z*p 8 - an incficator set to 1 if the LTL shipment size Is larger than -Cjp ; i.e.. segment s is partially or entirely cov- 
ered. NIote that Z'lp^s is always less or equal to Z*^^i . 

5 Algorithm Steps 

The following Mixed-Integer Linear Programming problem is solved: 
Problem (CI): 



10 



S.T. 

75 Initialize inventory positions: 
(C1.1) 



so System dynamics: (e«pected) beginning K) echelon 

ery quan% to the [X; during the last period - expected demand in the last period: 

(C15) 

x/=Xg'-'+s,'-'-,i,j" ij.t>1 

25 

Beginning (expected) inventory level needs to satisfy the requirement constraint, for the relevant frequency level: 



(CI. 3) 

30 



Only one frequency is chosen for each triple (DC, product and c^jarter): 

35 

(CI. 4) 



40 

Average echelon inventory (across all products) should not exceipd a given level. This level is given in terms of weeks 
of inventory. Note that we sublract one ha» since X is the beginning in^ 
over the period, i.a, X-yJ2): 

46 

(CI. 5) 



so 

Upper bouid on the numt>er of full truck loacte (FTl^: 

55 
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(CI. 6) 



10 

Lower bound on the number of FTLs: 



(CI. 7) 



IS 



20 

Defiveries not send by the FTLs are sent by LTL: 



(CI. 8) 



30 

Setting the transportation cost constraints (See 4.8.1): 
(CI. 9) 



35 



40 



45 



50 



55 



(CI. 10) 

^^ip,s~'^ip,e'X^ '^ip.s^l^^ip.s^i'^ip,3~^ip.3-l^ '^ip»s 

(CI. 11) 
(CI. 12) 



i»p# t 



i,P/ t,s 



i,p,t,s 



i,Pf t,s 



Integrality constraints 
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(CI. 14) 
(CI. 15) 

NFTi^In tegers 

i,Pft 



75 To estimate the operating paramrters, descrtoed above as part of the output of this model, use Model (04) (described 
later). 

Corrputing Maximal Average Levels of Service: Model (C2) Objective: GSven the delivery frequencies arxi limits on the 
average nurrtw of weete of (echelon) inventories, ths model calculates the maximal average service level that can be 
obtained. 

20 

Input 

Inventory Requirements (R* Line, see Model R) 
Delivery Requendes 
25 Limits on Maximal Inventory Investnrients 0" ternis of Weeks of Dernarid) 

Output 

Estimated Level of Service 
30 Estimated Transportation Costs 
Estimated Inventory Levels 

Notation 

35 We use the same notation as in Model C1 plus the following: 

a*y - >ojected" 0.e. nead^ime* periods after period t) level cl servte 
T^ - a given set c* periocte in which replenishinent (from plant p to TO 
Wjj - values of objective confidents (see discussion later) 

40 

Algorithm Steps: The following problem is of interest 
Problem (C2): 



45 




ST 

(C2.1)(G1.1) 
50 (C^.2)(C1.2) 
(02.3) (C1 .5) 

Formula used to approximate the "projected* level of service (see Model (0R1): 
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(C2.4) 

^to delivery (an be made in perkxte that are not 
{C2.5) 

75 S^J=0 for all tfT^p 



20 



25 



30 



35 



Note that Problem (C2) is separable both in I and in q. In addition, in order to deal with the non-linear constraint (C^.4) 
we appiaximate the Slandard-Nom«l cuniilati^ 

ments): for further details, see below. M^^^^ ^ 

As in Model (C1), we define tor the piece^wse Bnear function the parameters and vanaWes (fa further details, see 

below): 

m - rtarber of "segments" in the piece-wise linear function. 

^ - the s* breakpoint of the piece^wse Bnear function (s=0.....m); i.a the Srth segment is given by [ae^i . ^ ]- 
3s - the slope of the s-th segment of the piec^-wise fmear function (s=1 ,...,m). 

- the binary variat)les associated with this translormalion. 
Vio-ttie continuous variable associated with tNs transformation. 

In the tbitowing proWerrts we use Z*l^ and Y*j,8 respect to 



seebelow. 
Problem (02)^,: 

40 



45 S.T 

(CZ*.!) (C1-1) only for the relevanl value of i and ttQq 
(C2*5) (C1.2) only for the relevant value of i and tEQq 
(C2'.3) (CI.S) (sirJgle constraint) 
See the cfiscussion herein ftx d^ls on (C2*.4HC2\8): 

50 



55 
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(C2' .5) 



{C2' .6) 



{C2' .7) 



(C2' .8) 



j , t , s=l, - . - ,m-l 



j,t,s 



(C2*.9) (C2.5) only for the relevant value of I 
Remarks 

The weights Wjj shoUd be set such that 

.To determine the appropriate weights one should consider the relevartta<A)rs that need to be taken into account (e.g. 
priorities, dentand volumes, etc.) 

In case thai some products have low service l©^ete, the problem can be resolved with the adtfilion of the foOowing con- 
straint 
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{C2'.10) 

virfierevijareprespecffiedlowa^boundsonthelwe!^ whkrfi does mrt require the spectficalion 

of 9|is 

(C2'.ll) 

Mininrazing Average DC Echelon Inventory Levels: Model (C3) 

Cfcjeclive: Oven the delivery frec^encies and required service levels, this model conrputes the mininial average 
nurrt)er of weete of inventories at each one of the DCs in every quarter. 



Input 

30 

Inventory Recpiiremenls (R* Line, see Model R) 
Delivery Frequencies 

Required Sennce Levels (in Terms of Stock-out Pn)bat>imies) 

35 CXjtput 

Estimated Le^ Of Service 
Estimated Transportation Costs 
Estimated Inventory Levels 

40 

Notation 

We use the same notation as in Model plus the follcwing: 

45 pO)- the plant in which product] is produced, 
q(t) - the quarter to which period t t)elongs. 

RHi,j) - this is the inventory requirement as defned for Mcd^ R. txit without the subscript f. It now refers to the given 
delivery frequency from plant pG) to DC I in quarter q(t). 

AVG^i - the average ecfielon inventory level in terms of weeks of demand (for DC I in quarter q). 

50 

Algorithm Steps 

For each DC I in I: 

55 Step 1: For each product j.j€ J': 
Solve the foOowing prok)lem: 
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t 



5 



S-T 

(C3.1) (C1.1) (single constrain^ 
(C3.2)(C15) 

10 Beginning inventories must satisfy nvnimal requirements: 

(C3.3) 



20 



t 6 T. 



25 



30 



End For G) 
Step 2: For each q in Q 
Calculate the value 

{C3.4) 



35 End For (q) End For (I) 

Computation of Operating Parameters: Model (C4) 
Objective 

40 

GSven a delivery plan (I.e. the values S*,), this mode! computes the folloiwng operating values: (1) estimated inven- 
tory levels. (2) estimated levels of service, and (3) estimated transportation costs. 

Input 

45 

Delivery Plan (S*|). 
Output 

50 Estimated Level of Service 

Estimated Transportation Costs 
Estimated Inventory Levels 

. Notation 

55 

P* - Set of all plants that replenish DC L 
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Algorithm Steps 

For each DC I in I: 

5 Step 1 : Evaluate the expected (echelon) inventory positions at the beginning of each period via the equations 
(C1.1),(C15) 

Step 2: For each quarter q in Q 

2.1 Evaluate the value AVG\ via (C3.4) 
10 22 Evaluate the expected levels of service 0 via (C2.4). 

2.3 Evaluate total transportation costs over the quarter (can be done by an external procedure) for each plant . 

End For (q) 

75 Check Con^)ahl)i% of a Given S^ of Constraints: Mode! (C5) 
Ot)iective 

This mode! checks wrhether a set of constrains (service levels, maximal echelon inventory levels and defivery fre- 
20 quendes) is compatftile or not. 

Input 

Inventory Requirements (R' Line, see Model R) 
25 Set of Possible Deflvery Requenctes 

Required Servfce Levels On Terms of SlockK)ut Probabifities) 

Linfe on Maximal Inventory Irvestments On terms of Weehs of Demand) 

Output 

30 

Feas&ility(Vteorf4o) 
Algorithm Steps 
35 For each lln I: 

Step 1: For each plant peP: 

Setectthemoslfrequert among the feastoie defivery frequencies from plant p to DC I (this represent the less 

restrictive constraint). 
40 For this defivery frequency, evaluate the inventory requirements R^M")^ 
Cateulate the values X*| as in Model C4. 
End For (p) 

Step 2: for each q in Q 
45 Evaluate the value AVGi^i via (C3.4) 
Checkthat 

50 

is satisfied, tf not STOP! the set Of constraints IS inconpafibla 
End For (q) 
End For (I) 

55 Determine Production and Delivery SchediJes: Model (C6) 
Ot)iective 

This mode! suggests both production and defivery schedules which minimizes total transportation costs and 0"' 
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plant) inverttory hokf ng costs. The plan Is determined under service level constraints and constraints on average inven- 
tories at the DC (echelon) levels. 

Input 

5 

Inventory Requirements (R* Line, see Model R) 

Setof PossUe Defivery Requenctes 

Required Sennce Levels On Tenns of Stock-out Probabilities) 

Limits on Maximal Inventory Investments On temrts of Weeks of Denrand) 

10 

Output 

Delivery Requenctes 
Estimated Level of Service 
15 Estimated Transportation Costs 
Estinated Inventory Levels 
Estimated In-Plant Inventory Costs 
Proposed Production Plan 

20 Notation 

We use the sanie notation defined to this pdm plus the following: 
Parameters 

25 

hj - holding cost for unit Of product j On plant p(D), per period. 

inv^l - inventory of product j in plant (p©) at the beginning off the plannir^ horizon. 

M - l)ig" number (see (C6.5)). 

30 Sets 

10 - set of all DCs that carry product j. 
Decision variables 

35 

P ROD^j - production batch size off product j in period t 

INV^j - inventory of product j in plant p(D ai the beginning ol peri^ 

AlyofiUuii Steps 

40 

The following Mixed-Integer Linear Progranrwning problem is solved: 
Problem (C6): 



50 S.T 

(C6.1)(C1.1) 
(C6^)(C1.2) 

Initialize levels off Iniplant inventories: 

55 
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{C6.3) 



10 

Inventory dynamics 

beginning inventory = last period beginning inventory + production quantity in the last period - goods delivered during 
the last period: 

IS (C6.4) 

id 



20 



2S Delivery can t>e made only iff period t is consistent with the chosen delivery frequency: 
(C6.5) 



30 



35 

(C6.6)(C1.4) 
See (CI .3): 

(C6.7) 

40 



(C6.8)(C1.5) 
50 {C6.9)(C1.6) 

{C6.10)(C1.7) 

(C6.11) (CI .8) 

(C6.12)(C1.9) 

(C6.13)(C1.10) 
55 (C6.14)(C1.11) 

(C6.15)(C1.12) 

(C6.16)(C1.14) 

(C6.17)(C1.15) 

Options for Production Capacity Constraints: 
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(C6.18) 



10 



TOs set constraints represents indivkJual lin^ 
(C6.19) 



w J^^f-PRODficapp 



20 



25 



30 



Tl* set Of (X)nstrairTts is rele«rtwt,en the different pnxhK^ 

IS.^ SI(C6.19) represent a single constraint for each P«ant pn a^^ t). more constraints can be 
easily added. Note that Iwth In (C6.18) and in (C6.19) loMwr bounds can be introduced. 



Umils on Storage Capacity 



cimibHw ICR 18^ and (C6 19) analogous sets of constraints can be constructed in order to express, for each 

Operational Models (OP): 
Overview 

In this section wedescribeafanily of nxxlels. analogous to Models (C1MC3^^ 
d.J^^^SS^i^^teS«*)rthei)rM^ . ^ • 

kSSSiTZb^wWo advantage . ^ 

tSSSl^cSnSZrnx.edetan«^ 

Te^t^CS^t^SSl^^o^^n 
rMw^freouew it can be relaxed at any (arbitrarily chosen) period 

S^2SK^cir<ruSSe4 hii^^ v4»ndell>^es must be n«cte^|ddy). 

sho^^rs^jns^^^a*.^^ 

nonwd to incorporate the irtegervariabte 
50 Joint F»roduction-DeBvery Plan: Model (0P1) 
Description 

This model minimizes the total transportation and fBiplant) inventory hold^ 



35 



40 



45 



55 



Notation 

The notation here is sinilar to that of Model C6 with the addition of the following: 
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Pafameters 

req*= ■ requirement for echekMi inventory level of product j at DC I in period t in order to maintain a certain level of 
Vojected" level of sennce (see Mode! 0R1 for further clarification). Ttiis minimal level depends on the delivery 
schedule, see Modd R for explanation on how to calculate these values (very similar to the calculation of the values 
rff(ij)). 

- the same as xj but now without the quarter index. 



cap*p(k) - the avaflability of resource k in plant p. in period t 

xVk) - the amount of resource k required for a production of unit of product j in period t 
slorage*p(l^ - maximal total volume/Value (etc.) of inventory remaining at the end of period t in plant p. 
15 p^jOg - the volumeA«Iue (etc) of unit of product j in period t 

setii?)\- seti^ cost to irtttiale a production batch of product j in period t 

Sets 

20 NoDelip- set of perfods in which no delivery is alkiwed^ I. 

Decision variables 

PROD^j - production batch size of product i in penod L 
25 INV^i- inventory Of product j in plant pQ) at the beginning of perfodt 

SEP] - an integer variable indicating whether a setup is required in period t for product j. 

Algorithm Steps 

30 The foltowing Mixed-Integer Linear Programnwig problem is solved: 
(0P1): 

35 

S.T 

(OP1.1)(C1.1) 
(OP1.2)(C1.2) 
40 (OP1.3)(C6.3) 
(OP1.4)(C6.4) 

DeGveries can be set to zero at any penod the user chooses: 
(0P1.5) 

45 

Sij=0 i,j, teNoDeli^g,^^^ 



50 Echeton inventory levels must exceed certain levels: 
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(0P1.6) 



10 

{OP1.7)(C1.5) 

(OP1.8)(C1.6) 

{OP1.9)(C1.7) 

(OP1.10)(C1.8) 
75 (OP1.11)(C1.9) 

{OP1.12UC1.10) 

(0P1-13)(C1.11) 

(0P1. 14) (01.12) 

(0P1. 15) (01.14) 
20 (0P1.16) (01.15) 

Productrancapacfty constraints (see also Mcxiel (06)): 



(0P1.17) 

P,t,k 



Stomge capacity constraints (see also Model (06)): 
(DPI. 18) 

35 Pi 'INVfistoragep ik) 

P,t,k 



40 

Introducing setL4> costs: 

The operational model can t>e extended so as to include setijp cos^ 
The term 



45 setupf'SETj 



is added to the objective fi0Ktion of Model (DPI). 
50 Appropriate set Of constraints Should be added as weU;forinstance: 



55 
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(0P2.1) 



(OP2.2) 



15 This constraint is pertinent if product j requires a new setup in each period it is produced. (M is a Targe" nuvrber.) 

(OP2.3) 

20 . 

(with SET^i initialized according to the production/hon-production cl product j in the last period before the planning hori- 
zon). The intuitive behind this constraint is that if a product is produced in a given period, no setup is required at the 
25 sut)sequent period. 

Maximizing Short-Tenn Level of Sennce: Model (0P2) 
Description 

30 

The purpose of this mode! is similar to that of its tang-tOTi counterpart. Model (C2). In the same spirit of that mod^ 
(C2). we change Model (OP1) as fblkws: 

Algorithm Steps 

35 

(0P2): 



40 



ST. 

(0P2.1)(0P1.1) 
(OP2.2)(OP1.2) 

45 (OP2.3)(OP1.3) 
(OP2.4) {0P1.4) 
(OP2.5)(OP1.5) 
(OP2.6)(OP1.7) 
(OP2.7) (C2\4) 

50 (OP2.8) (ffi .5) 
(OP2.9) (C2\6) 
(OP2.10) (C2 .7) 
(OP2.11) (C2\8) 
(OP2.12)(OP1.5) 

55 (OP2.13)(OP1.17) 
{0P2.14)(0P1.18) 
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10 



IS 



20 



Remarte 

Constiainls (OP2.7HOP2. 1 1 ) use the piece-wise finear appraximalion to the Standard-Normal cumulative distrilxj- 
tbn function (CDF), see below. 

For explanation about the ooeffictents W|, see Model (C2)^j. 

Note that in this case, in contrary to Model C2, the problem is not separ^e in I. This is due to the capacity and stor^e 
constraints (OP2.13) and (0P2.14), respectively. 

Mininizing Average DC Echelon Inventory Lev^: Model (0P3) 
Description 

This model is analogous to the long^erm nrxxJel, (C3). 
We modify Model (OP1) as follows: 

Algorithm Steps 

Step 1 : solve the follGwing problem: 
{0P3): 



25 S.T. 

(0P3.1){0P1.1) 
(0P35)(0P1.2) 
(OP3.3){OP1.3) 
(OP3.4)(OP1.4) 

30 (OP3.5)(OP1.5) 
(OP3.6)(OP1.6) 
(OP3.7)(OP1.17) 
(OP3-8)(OP1.18) 
Step 2: For each DC I: 

35 Compute the values 



AVGt = 
(OP3.9) 



40 



45 



50 



55 
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MODEL 


WHERE USED 


Inventory positioning itlodels for multi- 
item and two echelons: 

Setting inventory requirements 

Estimating stock-out probability for a 
given replenishment quantity 


Strategic 
Plamning/ 
Operational 
Planning 


Strategic models for VMR contract setup: 

Computing maximal average service levels 

Minimizing average DC echelon inventory 
levels 

Computing optimal operating parameters 

Checking compatibility of a given set of 
constraints 

Determining production suid delivery 
schedule 


Strategic 
Planning 


Operational moaeis 

Determining joint production-delivery 
plsm 

Maximizing short-term service levels 

Minimizing average DC echelon inventory 
levels 


Pleuining 



Table 13 
Usage of VMR Models 



Conponert Procurement Poficy Development (CPPD) 230 
Objective 

D^OTHne whk*i procuremert polk;y should be used Ibr whwh cor^^ 
Scope 

Ail coTTYXMnents In planning bill of materials. 
Features 

Heuristk; to kJentifyttie procurement poBcy to use for each The policies considered are: Just InTime 

Bulk purchase, managed via slock policy, such as (s, S); and MRP calculus implying periodic pirchase orders. 

Finished Goods Dislrftxition Network Design (re^ 

Ot)jective 

Deterrrane the numt>er. k)catkm and capacity of distrilxjtion warehouses 



EP0770967A2 



Scope 



DistrSiution network excluding VMR arrangements. 



5 Features 

Use market demand projectk)ns to reengineer the easting dislnlxjtion network. 

Qobal optinizatton of syslenvwide cosis including intXHjnd /outbound transportation, fbffid and variable warehous- 
ing, and inventory carrying costs. 

70 

Model Engine Utilities 22 

In adcWon to the seven modules d^ined above, there is also a group of gen^ purpose numerical routines that 
are not specific to any of the dbove seven modules. These routines are collected into a design element referred to as 
IS the Model Engine utflities 22. as shown in figure 35A. Examples of the Model Engine utilities 22 include generic linear 
^ogrammlng solvers, and stati^ica! analysis routines. 

An ApprQximatk>n d the Standard lvk>rnrial Distrftxjtion 
20 Function 

In this sectkw, we suggest few contiruious. piece^wse linear approximations for the cumulative Standard Normal 
cfistrtxition cuva We use the foDowing notation throughout: 



25 



(A.l) 



30 



M 

1 : 



if6(jS-«<z<ei 
M 



Thisfunctionconsisl5 0fmsegn»nts.s=1,...,m Each segmerts. ranges ft^ ^i to break-point Bs- The 

stope of segment sis denoted by d^. Hence, any segment scan be written as the linear functfonas+asC^-Oa-i). In our 
35 model we limit the functions to be continuous (although unnecessary), t^^ 

(A.2) 



.) for s^2 



Note that In order to define the ptece^mse linear functkxi we only require the values % , s=1 .....n>-l and s=2,...,m-1 
45 (sinceai=dm=0). 



50 
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Remarks 


Symmetric, 
7 segments 


1 = -2.7, 
a = -1-8, 

3 = -0.9, 

4 = 0.9, 
s = 1.8, 
« = 2.7 


2= 0.039923, 
3= 0.164589 
^= 0.351044, 
5= 0.164589 
6= 0.039923 


Enables to reach 
reasonable level of 
accuracy oyer all 
argument ' s values . 


Symmetric, 
5 segments 


1 = -2.7, 

2 = -1-4, 

«3 = 1.4, 

^ = 2.7 


2= 0.057692, 

3= U . OOU /i* 

3^= 0.057692 


Less accurate then 

t* 7 Q^crments but 

requires less binary 
decision variables. 


Asymmetric, 
7 segments 


1 = -2.5, 

2 = -1-lr 

3 = 1.1, 

4 = 1.7, 

5 = 2.15, 

6 = 2.9 


2= 0.096904, 
3= 0,331213, 
4= 0.151834, 
5= 0,063973 
6= 0.021037 


Reaches good accuracy 
levels for the 
highest cumulative 
values , 



Table 14 



Linear Programming (MILP) 

25 Consider an LP/MILP which minimizes a (linear) function of the decision variables X=(Xi,...,Xm,. .»Xn) and their 
piecewise linear functions F^pc^), ^^9^, M ^ N. That is, an objective function of the type 

(B.l) 

35 with all dpO. Sintilarly to the variables Xm, .- ^ » the functions (XJ can appear in the (linear) constraints without 

any Emitation; i.a the constraints are of tfie type 

(B.2) 

40 s M 



45 F6rsinplicity,butwithoullossofgenera«y,weassuTneM=1. Ato,fc)rcl^^ =T. Wethus 

describe a technique that transfonns ttw function FfT) into a new decision vari^e, say H. such that the relationship 
H=FCD is maintained for any solution obtained by solving the new M 

Algorithm Steps 

50 

bek the function F'X*^^ be as follows: 



55 
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(B.3) 



F(T) 



M 



r=To=o 



F consisls Of m segments; segmert SB given by [x^i ,Tm]. We now introduce the follow^ 

Ys - Is a continuous variable (Yge tha* represents the part of 
(B-4) 

V3=max{min{^ ^, Tl-x ^.1 ,0} 

I3 - te a Binary variable (lse{0.1 ,2....)) that indicates wh^er ) that indicates whether T covers any positive part of 
segments; that is, 

{B.5) 



0 if r>T^, 

otherwise 



To mocfify the cun-ent LP/MILP we do ibitow the steps below: Replace each F(T) by the term 
(B.6) 



Add the following constraints: 

Ys (s=1 ,....m) are the spft of T into the segments. 

Hence. 

(B.7) 



To maintan (B.5). 
(B.8) 



Other constraints: 
(B.9) 



's^'s+i: s=1.K.m-1 



(BIO) 
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Mean 

This algorithm ranrputes the stetisl^ series for a given period of tim& 

The irput for the routine is the time series , and time peri^ 
sample mean quantity 



n 



10 




X 

IS 



Standard Deviation 

20 



The algorithm conputes the Statistical sanplestancfarddewa^ series for a given period of time. 



25 



The irput for the routine is the time series X, and time periods n that the standard deviation is computed over. 
The output is ttie unbiased sariple standard deviation c^jantity ax- 

30 

Moving Average 

The algorithm confutes the moving averages for a given time series for a given ^ 
aging periods. 

35 
40 

The input for the routine is the tirne series X, time periods n that the moving average is conpu^ moving 
average period length K. The output is the moving average quantity 

X(iO=Uj,(X) 



Seasonality Factors and Trend 

50 

Seasonality Factors 

The algorithm conputes the seasonaOty factors for a given time seri^ 
routine is the tinw series, and time periods that the moving average is computed over (at least two seasonal cydes). 
55 The output is the seasonality factors. 

TrerxJ 

The algorithm coirputes the trend information for a given time series for a given period of tima The input fa the 
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routine is the time series, and time periods that the trend is computed over. The output is the trerxl value of the time 



There are several different methods to calculate the se^onality factors and the trend in a time series. The most 
popular ones include Winter's conventional linear and seasonal exponential snrxxrthing. and (multiplicalive) decompo- 
5 sition method developed by the U.S. Census Bureau, and its variant X-11 method). 

Correlation Coefficient 

This algorithm conrputes the correlation coeff ident for a given pair of time series with property defined time periods 
10 (there might be certain shifts in time periods in the two time series). 

r (X, Y) = 

IS 



52 IXr^HYr'^' 
\ t-1 



20 The ir^ tor the routine is the pair off two time series X and Y and corresponcfing time peri 
con^elation coefficient for the two time seriea The output is the corrialation coefficient r(X,Y). 

Curve Interpolation 

25 This conventional algorithm determines a curve with desirable shape to link a set of given points on a 2-dimensional 
space. The irput for the routine is the set of given points, and the desired curve shape. ^ 
isfies the required conditions. 



30 



Weighted Sum off Two Time Series 

The algorithm computes the weighted sum off two time series. 

35 The input for the routine is the two time series X and Y, the weight ffactors a and p and the given time periods n. The 
output is the weighted sum time series 

Z=(2,)?. 

40 



Coefficient of Variation 

This algorithm conputes the coefficient (rf variation for a ^ven time series using urU)iased sfatistical mean and 
standard deviation. 




The input for the routine is the time series X and the given time periods n. The output is the coefficient of variation for 
the time series Cx. 

55 Goodness-of-Frt (Measure of Accuracy) 

Thfe algorithm computes tte goodness-of-fit (nreasure of accuracy for a given pair of time series: one is the origi- 
nal time series and the other *s the simulated one. The input for the routine is the pair of two time series, and corre- 
sponding time periods used to compute the goodness<rf4it for the two time series. The output is the goodness-of-fit 
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(one measure of accuracy) for a given simutated method. Themeasureof accuracy can take one of the following fonns 
(assume that X=XOi" is the original time series. F=(FOi" fe the forecast time series and ej = XpFj are the error terms): 
Mean Error: 



Mean Absolute Deviation: 

70 



IS Mean Squared Error: 



20 

Standard Deviation of Errors: 



25 



40 Mean Absolute Percent^e Error: 



45 



Percentage Error: 



Mean Percentage Error: 

35 



MAPE= 



Regression Equation 

50 

This conventional algoritfim computes the co^idents of a regression equation for a gven set of time series. We 
win cfioose a standard corrputatbnal routine to calculate these coefficients. The input to this routine Is the set of time 
series. The output wQI be the calculated coefficients of the regression equatioTL 

55 Si4)ply Chain Frame Manager 24 

Overview 

A Frame 1 6 is designed to integrate User Interfaces, models, analyst routines and data In order to address a set 
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of related decision issues. The Siwly Chain Frame Manager 24 constitutes the backbone of the DSS 1 0 through which 
the User Interfaces, the models in the modules and the data are connected. The Si^ly Frame Chain Manager 24 facfl- 
itates the integration of the dient side of the system, wwth which the user interacts, with the server side of the system 
where the modules and the DSS Database 12 resida 

The Supply Chain Rame Manager 24 is responsWe for two types of integration: System Integration and Functional 
Integation. The System Integrator 310 (see figure 34) is responstole to interpret the clienfs request, dispatch the 
request to the appropriate servers and to coordinate the computation load and data a^^ Finctional Integrator 
312 provides the functionafity associated with cverall supply chain instead of individual frame. These functionalities 
include Supply Chain Configuration, Domain Management user access or privilege administration and performance 
monitoring or simulation. 

System Integration 

The Frame Manager 24 is responsftsle tor the dient-server integration in the DSS 1 0. In tiiis aspect, the Frame Man- 
ager 24 provides the linkage between the Frames 16, Model Engine 20 and the DSS Database 12; responds to the 
dedsfen requests from the client programs by accessirig the models and data; and maintains the "conrponent ot^ects" 
(ag., object linking and embedding OLE objects) that share functionality b^ween drff^ent Frames 16. Based on the 
decision requests, the Frame Manager 24 launches the appropriate object witti the appropriate data, manages the 
requests from (fifffer^it dients for the same service and executes the appropriate server programs. The server pro- 
grams execute the request, and return the resutte to the Frame Manager 24. The Frame Manager 24 will interpret and 
return the results to the Frames 1& 

The high level architecture of the System Integrator 310 is shown in figure 35 and indudes a Qient Manager 320, 
a Request Interpreter 322 and a Server Manager 324. 

The architectural design of the Frame Manager 24 reflects maximum f lextoflity and robustness of the DSS 1 0. The 
dient side indudes all the User Interface 18 of each Deddon Support Frame, such as Demand Management. Supply 
Management eto The Frame Manager 24 includes tvw major pieces, the Functional Integrator 312 and the System 
Inteyalor 310. Two other conponents running on the server side are Decision Support System Database (DSS Data- 
base 12) and the Mathematical Model Engines 20. The dient program 314 talks to the Frame Manager 24. The Frame 
Manager 24 is the one responsibie to call individual components running on the server to fulf fli the dient's request 

For ©(anple, a user is working on a PSI frarne to devetop production plan lor a spec^ 
eral key parameters, the user wante to check on the production capacity. The user makes this request from the User 
Interfece 18 (cTick a button or select a menu item). The request is sent to ttie Frame Manager 24. The Frame Manager 
24 interprets the request and d^errnnes that rt needs to move the Capacity Checking Mo(tel to get the answer . (In a 
more general case, it may need to caDrnore than one Model to acconiplish the job.) Then the Frame Manager 24 deter- 
rnineswh^her a rnodel Server already running and on whwh machine it is running. If there is one. it sencte the capacity 
checking request along with the necessary data, to ttiat server. H there is no Server mnning at that time, the Frame 
Manner 24 wffl start up one on a selected machine and sends the request thera Sophisticated dispatching polk^tes 
can be inplemented at ttieFranie Manager 24 to balance the toad or inprcver^^ After the Model Engine 

20 finishes the job, it returns the result to the Frame Manager 24. The Frame Manager 24 then synthesizes the result 
and returns the result to the dient 

When the Frame htenager 24 calls the Model Engine 20, it has two options in terms of passing the data. Rrst, it 
can obtain the date from the DSS Database 12 and pass it to the Model Engine 20. This will be done when the amount 
of date that need to be sert to the Model Engine 20 is not very larga The advantage 0* this appr^ 
ular Model Er^ne 20 does not require the capability to access DSS Database 12. But the date has to travel from DSS 
Datdtjase 12 to Frame Itonager 24 and then from Frarnet^tenager 24 to the Model En^ne 20. The second way to pass 
datetothe Modd Engine 20 is for the Fraine Manager 24 to only pass the key iriforn^ directfytotheMod^ Engine 
20. Then the Model Engine 20 accesses the date directiy from the DSS Database 12 using the key infonnation. This 
wiQ be used when the amoimt of date needed by the Model Engne 20 is quite substantial, ag. a siti^tion of solving a 
Linear Programming model. The key information passed from the Frame Manager 24 to the Model Engine 20 will 
indude the focation of ttie DSS Database 12, among otiiers. 

The Qient 314 only interacte with the System Integrator 310 part of the Frame Manager 24. The Functional Inte- 
grator 312 part of the Frame Manager 24 provides the functionality through the System Integrator 310. The relationshp 
between the Fictional Integrator 312 and the System Integrator 310 fe logically the same as the relationship between 
the Model Engine 20 and the System Integrator 310. 

The System Integrator 310 in turn is composed off the Client Manager 320, the Request Interpreter 322 and the 
Server Manager 324. The Client Manager 320 manages and monitors the dient connection. For exanple, it may dfe- 
connect a dient if the dienfs machine is down or if the cOent is inactive for ext^ed period of time. The Server Manager 
324 manages the server side connection, ft is responstole to start up and shut down senders. It is also manages dfe- 
parching. The Request Interpreter 322 is the one that the dient directly interact with, ft wiD parse the dient request and 
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generate request to the servers, tt will corisuft with ttie Server hter^ger 324 before maWrig corm^ 
server. 

The high level object represenlaton of the system integrator 31 0 portion of the Rrame Manager 24 is shown m fig- 
ure 36 and the high level architecture is depicted in figire 37. TTie implementation documentation can be found in 
5 AppencfixC. 

Functional Integration 

The Functional Integrator 312 enables the advanced user to define the supply chain configuration, manages user 
10 access and privileges, supports and enables the customization of the DSS 10. manages domains to support user 
defined data groi^ings, manages user defined Scenarios 78 and ensures data consistency across the DSS 10, and 
dynamically monitors the irnpact of the users decisions on the performa^ entire supply chain by i^ing supply 

chain stnulation. 
IS Supply Chain Configuration 

The Supply Chain Frame Manager 24 allows the advanced user to specify the corrfiguration of the si^ly chain. 
The advanceckiser win be able to specify the structural (static) elements of the supply chain. These include: Customers 
or Equipment; Products or Repair Items; Components; Production Resources or Repair Resources; For each of these 
2o stmctural elements, the advanced user will be able to define the variois attrftxxtes such as; Names and the values of 
features; Grotp definitions; and Nodes and locations. 

In addition, the advanced user will be able to define the inter-retationships between these structural elements. 
These interrel^ionships include: Distances, costs, and flow Bmits on the arcs between the various nodes of the net- 
vwKk; Customer-Product-Resource (Equpment-Repair Item-Resource) relationshp matrix; Bill of Matenal structure 
25 that relates corrponents to producls; and Proiuction Matrix that rel^ 
products (repair iteiTs). 

The data flow diagram associated vwth the Sipply Chain Network Configurator 330 is shown in figure 38. 



User Access and Privileges 

30 

The DSS 10 is a secire system Where a userid and password are required for access and is managed by a User 
Access and Privileges Manager 331. An accourtconsisis of a userid. password a^ in various groiys . A 

user derives rights from group merrt)ersh^ that can be incfividually amended. The DSS System Administrator is 
responsible for assigning each user to a group and assigning rights to every new accourt The lowest access possible 
35 allows read only access to one specffic frame, with no abifity to save Scenarios 78 or do^ 
10 dal^t)ase 12 has a designated owner. Only the owners are allowed to update tt^ 

be used to update the DSS Database 1 2 when the user who generated it is the owner of the data table that needs 
update. 



40 Customization 

The DSS 10 is customizable to the application and environment where the tool vwll be used. The custonnization 
involves: Teminology and nomenclature. Modules and models in the Model Engine 20. Displays and reports, and 
G^raphical User Interface objects. ^ 

45 The first two aspects of custonrization are administered by the analyslfeystenrc adnrirtistrator. For the last two 
points of customization, the user has the flexMty to custonize dfeplays. reports and GUI ejects. The DSS 10 uses 
the proper terminology in the User interface 18 for the infonnation presented to be dear and intu^ 
forms to the users environrnert and nomenclature. The DSS 10 uses a table of ten^ 
dature suitdt)le to the user^ appfication environment Images on buttons as w 

50 local environment at either the time of installation or executioa Saeen appearance elements, such as colors and fonts, 
are modifaWe through a User Preferences window. The user has the abflity to change the layout of saeen elements. 

Domain Management 

55 The Sipply Chain Frame Manager 24 provides the user with the abflity to define combinations of products, custom- 
ers, and resources to be reused in the contextof various analyses. These are caDed Data Domains and are managed 
t>y a Domain Manager 332. 

Data Domains provide a convenient mechanism for the user to define the products and customers with which (s)he 
is interested in vwxking. For exanple. an account manager can define a data domain that consists of the a^mer 
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accounts thai (s)he is responsible ior. A data domain is a set of customer, product, or resource combinations. Data 
Domains may be used from different Frames 1 6. The data domain can be d^ined at various ley^els of aggregation (res- 
olution) ator^ each dimension: Pioduct/lxoduct group, customer/customer youp and resourcefresource groi^. A data 
domain is independent of a data source (forecast poirtt of sales, shipments). The data sources are determined 1^ the 
type of arralysisthat is performed and are therefore contingenton the frame where the data domain is used. l=or exam- 
ple, a domain can be used in the conte)rt of the sales prornotion analysis functionaS^ 

casting: different data sources wiD be used in order to perfonn each analysis but both refer to the sarne data dor^ 
Not attacWng a particular time range or data series to the Data Dornains fOTM 

tion and frame to frama The user is allowed to build, edit and delete DataDomainsthatareownedby the user. In addi- 
tion, the is allowed read-access to the definitions of the Data Domains of other users. This facilitates a set of users 
to perform sinilar analysis and share carefully constructed Data Donriains. The Data Donfiain Database comprises two 
tables: Domain Description and Domain Definitioa From these two t^es. the list of available user domains and the 
member tuples of each domain can be created and cfisplayed for the user. The domain management Interface can con- 
sist of multiple tree-views. Each treeview represents the logical groiping of customers, products or resources. From 
each of the tree-views, the user can select the product, customer, or resource combinations and add the selection to 
the domain. The User Interface 18 should optionally reflect the data availability, and the intrinsic relationship between 
the customers, producis, and resources. For eo(arTple.H the user chooses a spectf^ he should be able 

to choose only the products that are sold to this customer (or any product, depending on hts preference) to make a 
domain. Since a custorner (or product or resoun^e) can betong to muttiplecustorTier (or product or r 
user should be able to visualize the groups in which the customer (or product a resource) is a member. This can be 
visually inplemented by reversing the tree^ew. based on user selected customer (or product or resource). This tree- 
reversal wfll (fisplay the bottom-up version of the tree, rather than the usual top-down. Data Domains can ateo be 
dynanBcally constnxied based on the features of the product For example, a PSI user can use the domain manage- 
ment tool to d^e that a data domain to consists of Televisions with 1 9" screen and GR3A chassis. The tool will then 
generate a data domain that consists of all the televisions with these features. The data domains contains the data 
groups which a DSS user is interested in working. For example, a plant manager can deline a domain that consists of 
products and production resoirces. An air force commander can deline a domain that consists of airaaft and One 
repairable uiits. The domain can be defined at various levels of agyegation along each dmension. Once a domain is 
defined and saved, it can be retrieved and used in the context of various decision analysis. Rgure 39 shows the process 
of using the Domain Manager 332. and also shows the operations of the Domain Manager 332. 

Scenario Management 

In the context of the differert Frances 16 users generate changes to databases or instances 0^ 
can t>e saved as Scenarios 78 which are managed by a Scenario Manager 334. 
Scenark>s can contain: edited data, results of arKdysis. graphs arvJ charts, arvJ performa^ 
The Sufiply Ffaine Chain Manager 24 supports the folkiwing ft^^ 
Save: Scenarras are saved in the kx:al database 
Ljoad: Saved Scenarios are loaded. 
Edit: Saved Scenarios are modffied. 
Delete: Saved Scenarios are deleted. 

A Scenario 78 can be used to update the DSS Database 12 wtien the user who generated it is the owner of the 
data table that needs lifxtefteL The Stf)ply Frarrie Chain Manager 24 maintains the data consistency aaoss the entire 
DSS 10 by re^ricting the iJ|xlate of the DSS Database 12. Scenarios 78 have note fiete 

form coiTinenls. Scenarios 78 should have a date stanrp to incficate the tinieo^ Scenarios 78 are typ- 

ically defined within a frame and are associated with a user. Sceriarios 78 are specif 

the context of (fifferentf=rames 16. providing that the user has the adequate access privileges. This enables the outp^ 
of an analysis in oriefranie to t)e sawed as a sceriario and used as an input in the contort Scenarios 
78. while bekxiging to specifk: users, can be shared between users. A scenario may be deleted only by the user who 
created it or the system adninistrator. A user should have the fadfrty to bad the scenario from different workstations. A 
user should also be anowed to foad portions of a scenark) into a differed franie. For exar^ 

topKtown and bottonvup forecasts from the Demand Management Rame 1 30. and load the top<k]wn forecasts m the 
PSI Frame. The DSS 10 should warn the user in case cl data inconpatMity. A user is able models and the 

parameters that were used to mocfify loaded data. The user is tfien Me to apply these nmdels and parameters to dif- 
ferent data sets. 

A frame 330 has several fonns 332 ^sociated with it as depicted in figure 40. If the user attempts to dose a form 
on whk:h data 334 has been changed, the user wfll be prompted to Save the changes to a scenario. Abandon Changes, 
or Update the actual database. Updating the actual database requires necessary access privileges. A Scenario 78 '« 
anchored to a frame, and can have mult^e forms associated with it. A Scenario 78 can l>e toaded into the frame to 
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which rt is anchored, in which case, all the data and other information wiB automatically be loaded into the appropriate 
locations. Alternately, a Scenario 78 can be opened to access specific data that are contained in the Scenario 78. This 
feature wfll enable the user to load the data aeated in a different frame to a different frama To facilitate this implemen- 
tation, Ibnns are speeded to have a pre-spedfied number of data-lpocketSw" Bements of a scenario include: 
5 Header information for each of the data pockets in each of the forms of each of the Frames 1 6. For example. DM- 
H1l=:POS1245=P0int of Sales Infomriation May 25. 96; DM-H2]=TD1245= Top Down Information May 25. 96; and 
DM-1-I3]=BU1245= Bottom Up Information May 25, 96. 

Model and paranteter infbmiation. For example, APMA with (1 ,1) applied to Top Down data. 
G^aph and parameter Information 
70 User comments 
Date stamp 

Performance monitoring using sinrulation 

Two levels of integration required in supply chain Decision Sifsport Systems have been embedded in our DSS 
art^titecture; data integration and decision integration to provkJe a Networi^ Sirnidator 350 (see figure 37). The former 
has been obtained by having a common Decision Support System (DSS) Datebase 12. from which input data to the 
decision models are retrieved and outputs updated. having such biKlirectional data flows between models and the 
Datdt>ase 1 2 a conplete data level integration is realized. In order words, all decisions are based on consistent and up- 
tc>date infomration. This is the primary level of irtegration for a supply c^ 

The secondary level of integration is the decision integration. The purpose is to avoid sub-optimization among func- 
tional processes. An ideal case would be to have a "meta analytical decision model" which could optimally solve the 
entire siwly chain wkJe problem. With the state of the art in decision sd^^ this is not . Thus, in our 

DSS architecture, various Frames 1 6 are Bnked by the performance simulator. For instance. Forecast Data 1 46 from the 
Demand Management Frame 130 is used in PSI planning and VMR 250 frames. VMR scheAiles are entered to the PSI 
planningandsoon. With this approach, it is necessary to have a supply chain wide performance simulator to monitor 
the ^fecls due to the systenrisdynaniics along the siwlyc^»^ integration. The purpose of such 

an intonation is to pro^e the user visibility beyond his functional boundary in order to fadlitate a feedback control. This 
feedback will make it possWe to dynamically monitor the impact of his decision on the performance of the entire supply 
chain. 

The discussfon befow begins with background on decision integration and the system architecture. Then, the 
undertying supply chain simulation modeling logic with regards to data flow and process ftow are described. Finally, 
originality of such an approach to use a supply chain simulator for the DSS integration is discussed. 

35 Level Architecture 

The Sirnulator 350 resides at the Siwly Chain Franie Manager 24 as a Func^ Integrator 312 togelher with the 
N^wort« Configurator 330 and Donwin Manager 332 as shown in figure 37; Supp^ 
Architecture. The Sirnulator 350 can be initially configured with product ftow. netww 

with the other modules of the Functional Integrator 312. Thea the Simulator 350 will read major dedskxis from the incfi- 
vidual Frames 1 6 that will have inrpact on the total supply chain perfornia^ 
driven by demand processes c^rtured from the donrain infornration and replen^ 

Frames 1 6. Total systems perfonnance representing the supply chain dynamtos will be tracked according to the per- 
formance matrices specified in our DSS specification. These rnainly cover cost and service tradeoffs indu^ 
and response tirnesw The perforrrance will be rnonitored in aggregation according to various le^ 
etons, cfistrixition channels and the total systera In essence, the architecture to^ 
plementing dedsfon integration among models to provide a cross-functional optimization. 

User Interface 

50 

User Interface 1 8 of the performance Simulator 350 wiD have three nrajor features; networic configuration, decision 
and parameter settings and the simulation and monitoring. 

Networit Configurator 

55 

The system will invoke the Networic Configurator 330 module of the Functional Integrator 31 2 at the Supply Chain 
Rame Manager 24. Detailed features and User Interfaces have bew described in the prevfous sections. 
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Decision and Paramefter Settings 

Parameter, frame decision settings and ennpirical demand dislritxjtions wfll be displayed in the editable saeens. 
These saeens wfll also be accessible during the simulation nm so that the user can interrupt the execution and modify 
the paramrters interactively. The foDowing screens are included: Demand distribution screens and Frame decision 
screens. 

Performance Monitoring and Simiiation 

The user is *le to visualize the inr^)acl of the decisions taken at the level of one frame on the overall performance 
mrtrics of the entire supply chain. The Supply Frame Chain Manager 24 supports this perfbnnance monitoring func- 
tionafty. In an the Frames 16 users can easily access the -perfomf^^ saeea" The performance monitor- 

ing screen displays gtobal performance metrics that are available to 

The perfomiance is tracked and displayed atong the: channel (such as VMa Non-VMR, ^.); echelon (such as si^ 
plier. plant DC and stores): individual nodes; and the total system. The performance monitoring screen also contains 
user fomwtetfid perfbnnance metrics that are custornizableand avaflaWe only to the user who formulated ttiem. 

The Supply Frame Chain Marager 24 stpports the faitowing functions for user formulated perfomiance metrics: 
Fbnnulate: a new user-fbnnulated performance metric, Ecfit: an existing user-fbnnulated perfomiance metric, and 
Delrte: a user-formulated performance metric. The function "ecfit" and "delete" are restricted to the user who defined 

the performance measura - ^ , , 

The vafoe of the perfomance measures can be updated each time the user modifies the valu^ 

database assodated with the frame in whk* the user is woridng or by ^ 

specified time intervals. 

Users can choose "a tk*er-tape" to always cfisplay the cun^enl values of user selected key measures. 
The User Interface 18 is desired to support the conventional "Visual Interactive Simulation (VIS)" approach. 
According to this approach, the simulation can be carried out not only in the b^ 

or period-byi>eriod mocte. The performance metrics could be viewed and parameters adjusted interactively. To facflitate 
this approach: 

Inventory, service level and cost profiles for each aggregated measure (such as node, channel or echelon) will be dis- 
played as time series graphs. This will higWight the systems dynamics atong the chain. 
Sunwnary perfomiance matrices wBI be displayed in the summary report saeen or saved to a file. 
Simulation Lo^: Data Row Descriptfon 

The sijpply chain sirnulatfon model primanly minacs the material a^ 
sions atong the supply chain (see figure 41). The Simulator 350 is built around data tables for each node which are 
linked accortfing to the information and product ftow. These data tables are stored as simulated data in the system. 

In the initiali2atk)n phase, these data tables wiD be populated with inventory infomnation including inventory posi- 
tion, on hand, on order and schedule receipt Thea these tables are connected using p^^ 

structire, order and product ftow dirediona Then, demand arKl lead time information is toaded from Demand Mana^ 
men! Rame 130 through system integrator and appropriate cfistribution 

are generated accorrfng to the demand processes at the customer facing echeton and replenishments are triggered 
accortfing to the control riles atong the lofipslics ppe line for each evert 

The ma^K inputs required are the decisions that win elfect the tot^ ThefbUowing 
are included: FGDND or N^work Configurator - Networic design and Product ftow. Demand Managemert - Forecast 
and forecast wrors; Venctor Managed Replenishment - Replenishmert poficy. Target inventory, and Delivery frequen- 
cies; PSI Planring - P line and its variation, and r line and its variation; Supply Managenrwnt; and Componert inventory 
poficy and parameters. 

Depentfing on the configuration of the networit, other supply chain system parame^ 
parameters may also be needed for the non-VMR channel. 

The outputs from the model are based on the performance assessnrtert plan of the DSS 10 for a commercial settng 
including the fdtowings: Supply responsiveness, On^ime delivery perfomiance Fill rate, FG inventory levels, Compo- 
nert inventory levels. Order cyde time, and Rnandal measures. 

The Simulator 350 buikte up the above performance metrics from the evert-level (lowesi) measures. This "bottom- 
up" approach in simulation makes it possible to support user fonnulated perfomnance matrices that will be custonraza- 
bla 

Simulation Ljogic: Process Ftow Descriptton 

A moredetafled process ftow of the simulation engine can be described in terms of other the demand processes 
or the control mies. Two basic control rules considered in our DSS 10 are production (recondliation) policies and 
replenishmert (inventory) pofides. 
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Demand Processes 



The perfomiance of the total si«rfy chain mainly depends 
the multiterel material and inlomiation flows from the supplier to ctstomers. Both independent and dependent *m»>d 
processes will be sipported. They (ictale the vwy requirement at each node is generated. In the independent demand 
customer orders are generated to aB nodes from random dislrlxitions deiretaped fTOT 
noda In the dependent case, customer order generation from the random cBslrftwtion is applied only to the cu 

facing echeloa The deinand for the higher echetons are calculated from the lower ones 

The following systems will be driven by independent demand processes: Vendor Management Replereshment 
(VMR)- Continuous Replenishment (CR): Reorder Point System (r. Q); Just-irv-time (JIT): and Min-Max (s. S). 

Thefollowing systems win be driven by dependert demand processes: Distribution Requiremert System 
(DRP)- and Materials Requirement Plaiming System (MRP). As for the case of One-fbr-one (S-1. S) system tor the 
repair Systems. Pbisson demand process wffl be applied. Demandgeneration will be carried out by an inverBetraretorm 
of the specified distribution. For t<gh volume items, nomal approximalion of forecast 

enpirical cfistributions wffl be used. Time series forecast and its wmr distrtoution (or parameters) vnll be obtained as 
frame decfeions from Demand Mai^gement 

Replenishment Processes 

Both pull versus push controls are sifjported. In the pdl control system, inventory is depleted by demand and 
whenever H reaches the replerwhmert point an order is placed to a suppHer. In the NflWIR. the suppTw 
Older to the store. F=or the demand channel, inventory decision processes (models) for the following pull systems will be 
included- Vendor Management Replenishment (VMR): Continuous Replenishment (CR): One-for-one Replerashment 
(S-1 . S): Reorder Poinl System (r. Q): and One*r-one system for repair will be togically treated the same as the Con- 
tirwous Replenishment in the commercial settings. , _t- 

For the push (planning) systems a timfrphased plaifor the planrting interval is established and replenishment is 
triggered based on the requireiiienl. schedule receipt and on hand inventory. For the demand channel. puD systems 
are: 

Distribution Requirement Planning Systems (DRP) . ..^ , 

Simaarty, for the siWJiy channel, the following puO systems will be supported: JustHn-time (JIT); and Mm-Max (s. &). 
The push planning systems for ttie supply channel are: 

Materials Requirement Planning System (MRP) ,■ 
Transportation and infonnation flow loffc wBI be enfoedded in the replenfehmert processea The cap^ 

tions. cost and lead time for various modes of transportation and inlomiation ftow (orders) wffl 
ttie replenishments. 

RecondGation Processes 

The production planning togic refers to the way MPS is aeated. CSven a PSI plan 1 90 for the planning horizon with 
possible variation, the system need to track the dynamic outcomes along the sipply chain. This will be earned 
generating the dynamic demand along the demand channel and consolidating them to obtain the simulated 

simulated S" Bne(lne rrfers to as the time series sales infontiatfon) will be checked against P' (production) and r finven- 
tory) lines of the PSI plan 190 to coinpute service fil rates. Then production plan P* fine will be offeet by Sim 

duction lead times. 

Once the actual P Bne is established, component usage can be computed using the Bfll of Material (BOM) tables. 
This usage is translated as requffements (demand) to the supply channel. Then, component flows along the supply 
channel will be traced acconfing to the respective component replenfehnfwnt poIici« 
nodefolfowing a similar lo(pc as described in the demand channel. 

User Interlace 18 

One of the primary objectives of ow DSS 10 is to provide a decision support environment that fadfilates 
sion<naldng processes using quantitative models and associated business data The interaction between the 
the DSS 10 during the decision-making process can be characterized as foltows: The conmwinication of pn^^ 
mation and management input: Fwmulation of dedsfon problems: Generation of problem solutions or evaluation of 
decision alternatives; and Coorefination of the above. 

To fadlitale the cornnuinkatfon and cooidinalion between the users and the OSS 10. it is ne^ 
appropriate User Interface 18 design paradi^n. 
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User Interface Design Paradigm 

The User Interface 18 is t>^ed on the conventional human computer interaction paradigm referred to as "direct 
manipulalion-. In this paracfigm there is no dear separation of input and output For example, in exercising a certain 
model the user may either evaliote the impact of a decision option ly specifying the decision variables or generate the 
optimal values of the decision variatjies. In the former setting the decision variables serve as input whRe, in the latter 
setting, the decision variables constitute the output 

Another chaac te r i sti c of the (firect marqpulation paradigm is the quick feecft>ack feature where a user initiates an 
action such as posing a particular query through direct manipulation of some interface object and the system responds 
with reasonable speed. 

User-DSS Interaction 

In each Decision Sif^port Frame discussed previously, the users will be aided In making several decisions. The 
princf>at process underlying these dedswns wiD serve as the basis for the design of the User Interface 1 8. 

A typica! user-DSS 10 interaction (see figure 42) begins with the users reviewing 402 the initial conditions and 
d^ult values related to a decision problem retrieved from the DSS Database 12. Then the users communicate their 
preferences ttvough proper selection of options, spedfkatfon of parameters and values, and choice of analysis rou- 
tines. The DSS 10 examines the inputs provided the users and assists the users in resolving any inconsistency in 
the irputs. Then, to k)ok for the solution of the problem, the DSS 10 invokes 

ply Chain Frame Manager 24 associated vwth the frame executes the appropriate quantitative models and routines in 
the Model Engine 20. The users can review the output through the User I nterface display, and repeal the above process 
if warranted. 

The general guidelines for the preferred User Interfece design are descrft>ed in the next sii)section. 
Design Guidelines 

The general design guidelines are as follows: 

User Friendliness 

Intuitiveness: Confonnance to established standards. 

Inte^ated ^aphical display: Simple and visually dean graphical screen layout 

User custonrtizaAion: Ability to customize the interface into user 

Minimal typing: Use of rhenus, puD down fists and buttons. 

User Guidance 

Flexible sequence control: Abflity to access the DSS 10 functionality without a pre-imposed sequence. 
Context-sensitive on-line help. 

Semantic feedback: Ltee of visial arxJ audio cues for confirmation and progress. 
Use of cok>rs for darity, focus and aesthetics. 

Usa' Meractfon 

Data visualization: Visual akfe to interpret date. 
Object orientation. 
Local/lremote corKurrent usaga 

Single/groijp usaga Ability for nuttple users to collaborate in 

Multiple levels of user expertise: Support tor novice as welt as advanced users. 

Inplenientation Principles 

Consistency: Similar look and feel' for userinterface objects across the DSS 1 0. 
Modularity: Reusable and objectK)riented user-interface coda 
Configurabflity: Adaplabflity to the specffk; user environrnent 
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Design Bements 

The key design elements for the DSS User Interface 18 include; Frame GUI; and Standard Object Lbrary. 
Frame GUI: Since the DSS 10 will be an interactive environment, we adopt the most common environment used for 
5 interactive computing, known as the WIMP environmerrt which stands for Windows, teons. Menus, and Pointers. A 
frame-specific graphical User Interface (GUI) in ths environmerrt is necessary to support the interaction (between the 
users and the DSS 10 in a decision process. The Frame GUI is customized using a standard set of User Interface 
objects An exarTV)le of this Fraine GUI is gh^en in figure 43. 

^andard Object Library: The standard set of the User Interface objects used to buiki Frame GUIs is contained in a 
10 stendard object li>rary. The forrns, positions arid contents of the obje 

Frame GUI. For example, these are the sanple objects in the standard fibrary errployed in the PSI DSS shown in figure 
43. 

Selection : to choose among various action options 
Grid: to input data and display results 
75 Chart to display input data and results graphically 
Comrmnd Button: to execute an action 
List Box: to list user choices 

Exanple Inplementation Arcfvtecture 

20 

The basic objective of the DSS 10, is to provide customized decision si|)port for the decision makers to manage 
an integrated agile supply chain. It generates the folfowing two specific systems requirements: DSS 10 shouti provide 
decision support capak>aities that work with the prevaOing information systems which is mainly data transaction based 
systems. These decision support capabflities may include data analysis, decision process modeling, scenario manage- 
rs ment among many others; arvl DSS 10 must integrate data from various sources along the Supply Chain Information 
Systems 15. This requires the DSS 10 to interact with multiple irrformation systems to gather raw data and cfistribute 
processed data. 

These two basic systems requirements motivate the architecture and the choice of the platforms. 
30 Three-tier DSS Architecture 

In an enterprise-wide supply chain, the potential users of the DSS 10 are decision makers with different operatfonal 
responsd)aittes and concem& The views about the supply chain and functfonal requirements for decision support 
therefore vary accordingly. The data to support these functional requirements reside often on a nunrt>er of informabon 

35 systems possbly with cfifferent hardware and software platforms. Consequently, the DSS 1 0 needs to interact with the 
users through a uraTted User Iriterface 1 8 to address diverse business concerns whne it s^ 
facing wHh dHferent Supply Chain trrlormation Systems 15 to gather 

To that end, we have developed a layered systems architecture design for the DSS 10 as shewn in figure 44 in 
which all rnajor system coriponentsiriteract with each other in a layered fashion Aside from other benefits, the layered 

40 design makes the cfioice of platforms as well as irrplementation of individual system components relatively independ- 
ent and penmrts standardized interfaces among various system cofrponents. The DSS architecture can also be viewed 
as a three-tier architecture consistent with the commonly urvierstood three4ier client-server information systems archi- 
tecture consisting of the User tnterfoce 18, the Business Logic 350 and the Data Management tiers 352 as fltustrated 
in figure 44. 

45 Each of the three tiers in the DSS architecture has its (fistinctivefuncti^ 

system conplexities. The platform for tfm three tiers is preferably chosen to best fit the user's unique fun^ 
tem needSw The choice is corrplicated by the availabflity of a nurrt)^ 

and the realization that there may not exist a single "optimat* suite of platforms. In the following, however, we descrfoe 
a suite of platforms that can best serve the general DSS 10 needs and also be in line with the forecasted future devel- 
50 opment trends in information technology and enterprise-wide distnlxjted computirYg technology. 

Selection of DSS Development Platforms 

To support the supply chain wide decision making, the DSS 10 neecte to be integrated. flexSile. responsive and 
55 conprehensive. One major obstacle, however, is that most of the data required by the DSS Database 1 2 are stored in 
various Supply Chain Information Systems 15 that are based on an older information and corrputing technology, 
designed to support vertically integrated organizations, built in isolation, and usually very corrplex. Such systerrw are 
generally referred to as the legacy systems. Therefore, to meet business and systems needs, the DSS 10 environment 
should: provide common and easily understood interfaces to all users, enhance the current business knowledge and 
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sWBs. model and incorporate business togic. and prom^ 

"^e devetopment ptettorm environment 370 illustrated in figure 45 has been chosen as the preferred environment 

'"TttTdXS'^I^^aTO.I^ Visual Basio372is^ 
the Business^ 350 that indudes Ihe Frames 16. Supply Chain Frame Manager 24. syst^ 

Model Engine apportions of the l^el Engine 20 thai requ^ 

preferably invlemented using the Visual C++ programming language 374. ^^^Ainr^ 
•^^SeXisS Basic codes 372 directly interface with the DSS Database 12. Hie DSS Dalat^ ^?J«^^ 
Access 376 which, in turn, interfaces with the S^ly Chain lnfom«tion Sysl«ns 15 ftrough erther Wind«« ODBC 
(Open Dalaba6eCom«clivity)tools378or Microsoft SQL Senrer 380 inacfientfee^ 
n^SysteiTB 15 can indutedala servers in IBM SQLTOS. UNIX Grade, among olherfornrats. 
^elS^ NT 382 is operating systems for the local area net«xk server 

any Windows environment p.1 and above) 384. .. . ..^ u. noc n<i4.h»o i9 

In this environment, it is inportant to establish the dientfeerver data tankage between the DSS Database 12 
fAtscessendneVand the supply ctein information system data servers. 

^deSi>ed earlier the DSS Database 12 is internal to the DSS 10 implementation and contains only the data 
needed for the execution of the DSS 10. The data in the DSS Database 12 is synthesized from a variety of s^^ 

S^SS^S^ System 15. The DSS Database 12 can be uTterf^ 
SaSmafion sources for data retri««l and update, as needed. This diert-servw 
Setiges dscussed below. It ensures that the DSS 10 can be 1.^ 

sources inihe supply chain. TWs is particularly sigrtficant in the absence of an «««'Prftr?.^'Tl!Sl^ 
SS«n for the chain. It reduces the burden on DSS Database management by obtaining "Pda»ed data only 

for a generic sifjply chain architecture and ninimizesapplkationspedficcustomiz^ 

WdSe described herein is built .pon the general dientHsen^ 
hard^ system ardtitecture (see figure 4Q for generic systems, in whidi the host 398 repr^ 

^^S)nS?^5. and tile PC^inthe Local Area Network (l^ 

aSS^awxKts^ng the invention described on various types of storage induding RAM. ROM. hard and 

'^^^ecturBoffigure46.weassume1hatthehosts398conlainthemajorityoftrar^ 

wiD communicate with an LAN 402 where the DSS 10 resides. Here, we do not make speaf ic asajnptois 

J^^ITIS (IBM mainframe or UNIX wor1«lation).0n^ 

lir^ dient PCs 400. SpedficaDy. the fundions of the DSS 10 can be partitioned as illustratediri figure 47^ 
35 BetowwedescribettTbasicsystemrec^iirementsandfundMnsforthesystema^ 

LAN: 

Basic Reqinrements: 

Local area network supporting standard protocols such as TCP/IP. IPX/SPX, Named Pipes/NetBEUI etc. 
PCs can am Windows NT or 95 

Basic Functnns: 

45 

Provide the corraTwnicalioninecfet>e4weencfient PCs to server PCs 
Pern* external PCs to clal into the network using regular teleph^ Ones 

AUow connection to the IBM hosts 
50 Client PCs: 

Basic Requirements: 

Have sufficient speed and memory 
55 Have network connection (on the LAN a dial-up through telephone line) 
Can run Windcws 95 or NT 
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Baste Functions: 

Serve as OLE clients 
Provide primary User Interface 
Inplement wtiat4f scenario manager 
Contain locafized database 

Server PCs: 

Basic RequirenDents: 

Have maximum speed, storage space, memory and network connectivity 
Run Windows NT. SQL Server and SNA Server 

Basic Functions: 

Be the OLE server 

Host main DSS Database 1 2 with a lixary of SQL queries 

Serve as the SNA Sender to escchange data between the DSS DB and host data tables 
Implement model object Ibrary 
Contain external cptinttzation solver 

Hosts: 

Basic Requirements: 

Standard IBM database and applications or UNIX based database 
Support any combination of the options (Ethernet, Token-Ring, or FDDI) 
SDLC 

X,25.QLLC, eta 

Bask: Functk>ns: 

Provide raw SMpply chain wide transaction data 

Contain EDI or other connectk)ns with customers and suppliers 

Support overall business information requirement of the connpany 

Example of Use 

User Access and Privileges 

When the DSS 1 0 is invoked, the DSS logon (fiatog ba« wHI be dis^ 
a valid User ID/Password connbination resuHs in the DSS 1 0 immecfiale^ temiinating. Correct entry of a vaKd user ID 
and password results in the DSS 10 being started and the opening screen being cfisp^ 
visWe as it is typed by the user, but the password is bk)ckBd to prevem casual observatk^ 
user ID is checked against an internally maintaiiied table to ensure authenticity and user's privilege. 

Opening Screen 

Once the user has successfuOy togged on to the DSS 1 0. the opening screen is presented. Presenting the opening 
saeen and deckling which frame the user is aUe to access is the responstoility of the Supply Frame Chain Manager 
24. The main feature of the opening saeen is a graphical outline of the stpply chain overiakJ with the relevant Frames 
1 6 and sfwwing the relevant portion of the stpply chain. The user may move the mouse pointer over any of the Frame 
Boxes and dk:k within the box to launch the frame (see figure 49). 

The user may also (firectty ^x;ess the Frances 1 6 from the Toolbar buttons. The user must have the correct privi- 
leges to access the selected groi?>, or an «Tor message will be displayed alerting the user that he does not have the 
con^ect privileges. 
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User Preferences 

A feature of the DSS 10 ayailat)le from the main DSS screen is the User Preferences Folder. This folder allows the 
user to change certain features of the DSS 10 to preferred settings. Aspects of the SCTeen 
5 tionaBly vwO be mocifi^e by the user. These pr^ences are saved and remembered between dffer ent DSS 1 0 user 
sessions (see f^e 50). 

Domains 

10 Select Data Domain 

The primary interaction screen for the Domain functionality is the Select Data Domain dialog box (see figure 51). 
The purpose of this dialog box is to display a Bst of aD domains available to the user, ft 

(fialog boxes for, editing, aeating and deleting user domains. This set of functions constitutes the core functionary for 
IS the domain ob}ect 

The major.features and functionarrties of the Select Data Domain dialog box are discussed below. An area showing, 
in a gaphical way, the available domains. This list is buift from two separate lists of domains. One set of domains is a 
de^tt list of domains available to all users. The second set of domains is a user-specific set of domains. This set of 
domains can be created, edited and deleted by the user. The defauft set of domains is immutable. Each domain is rep- 

20 resented by a folder. Double dicWng on a folder selects the folder and adds it to the 

Double clicking on a foWer expands the folder and shows the customer-product tuples that are within the domain. An 
area showing the currently selected domain name. A button to aDow Loading of the currently selected domain. A Cancel 
button to allow the user to exit the dialog box without selecting any domain and without initiating a load operatioa The 
Cancel is only vafid for operations performed on the current dialog box. Editing operation performed during the session 

25 wiD persist. An Edit Domain button to aDow users to modify existing domains, create new domains and delete unheeded 
domains. This functionality is only available for user-aeated domains and not for default domains. 

Edit Domain 

30 The Edit Data Domain functnn allows the user to create new, user-d^ined domains and add them to the list of 
existing domains. In addWon, the edit domain window allows the user to modify existing domains and delete unneeded 
domains. The user can create tuples from a tree-like Ifeting of all available products and product groupings and all avail- 
able customer/custorner groi4)ings. The user rnay add as rnany tuples to the nw 
give the doinain a unique name and save it ft is then added to the Bst of avaBaUe dorna 

35 The rnajoT features and the usage of the features of the Edit Data Dornaindi^ 

ate a new domain, the user must dk* the Add New Domain button on the tool bar. This will create a new domain in the 
fist of costing dornain and open a narfie change box over the narne of the domain so the u^ new domain 

a unk|ue narna To add a new tuple to a dornain the user rnust have a selected dorviain in the dc^^ 
must d«k on a product or product group in the product tree and^or a customer or cuslorner g^ 

40 and cfick the Add to Domain button on the toolbar to add the selected tuple to the selected domain. Only one prod- 
uct/k)rDducl yotp and one customer/customer groip may be selected at a time. Selecting a goip will resuft in agge- 
gated data for the selected group being cfisplayed. If data for the members of the group will be needed, the system wfll 
assist the user by displ^ing the data al ^jpropriate resolutfoa HcM^^ 
for the rnenfoers be toaded. A shortcut key win be provkled to altow the ^ 

45 that make ip a selected groupi The user may select as many tuples as necessary. To remove a tuple from the new 
domain, the user must select the tuple from the W of tLples to be added to the new dornain an^ 
on the toofoar. To delete an entire doniain.highBgm the donriain to be deleM Delete 
button on the toobar. The user will be warned that this actfonwHl resuft in the efiminatioo of a domain from the DSS 10. 
If the user dkte OK. the domain is deleted. If Cancel is drcked, the domain vmll not be deleted. When naming a new 

50 domain: the new domain may not have the same name as an existing user domain nor the same name as an existing 
d^auft domain; and the domain name shouU be something descriptive to the user so he will remerTt>er what the 
domain represents. The user saves the new data ctornain and exits the diatog box t>y selecting the OK but^ fttheuser 
exits wrthout saving the new domain, hetehe wfll be asked whether the new domain shouW be saved. The user can exit 
the diatog box without saving the new data ctomain by cfiddng the Cancel button. Defauft domains carrot be added by 

55 the user. Defauft Data Domains are aeated and added to the DSS Database 12 by a systems adntinistralor wfth this 
access privilege. The user may choose beiween four differerrt modes for viewing the Customer and Product trees as 
dscussed below. The Troduct View* enables the user to f»st dk* on a product or product group in the Product tree. 
When a product or product group has been selected, the Customer tree is updated to dsplay only the customers and 
customer groups that are relevant The "Customer View" enables the user to first cBck on a customers or customer 
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group in the Customer tree. When a oistonrier or customer group has been selected, the Product tree is updated to dis- 
play only the product and product groups that are relevant The 'Customer-Product View" enables the user to firsl dick 
on either an element of the Customer tree or an element of the Product tree and see the existing related elements in 
the other tree. The "Tleutral \^e«r displays aD customer and customer groifjs and all product and product gn^ 

5 no Bnkage between them. This view allows users to sdect tuples without regard lor the exisling relationship between 
the products and a custonrer. The user also has the abaity to reverse the tree and show all the parental relationships 
involving a selected element of the tree. This is accomplished by way of the Reversed check box located at the top of 
the Customer and Product trees. By cficWng the check box the tree is reversed, based on the c^ 
of the tree. Either a group or an incfividual product or custorner rnay be selected. The tree 

10 the 90if>s it belongs ta To restore the view to the nornial view, uncheckthe check box. 

The user may deselect any selectkxi made in a Product or Customer tree by clicking the Deselect button located 
above the desired trea This wiD remove the higWi^ bar from the currently selected tree element and leave aD ele- 
ments of the tree in the unselected state. This is useful rt the user wishes to select an element from only one or two 
trees, but not all. 

15 

Make Product Set 

The Make Product Set dialog box gives the user an alternate way to rnake a doniai 
and product groups (see figure 53). Using this cfiatog box, the user rnay select gro^ 
20 tures of the products. This function can be accessed from the Ecfit Data Donia^ 
Set button on the toolbar. This win open the Make Product Set dialog box. 

Rrst, the user selects a product category from the product category Bst Then, the user selects a feature (or fea- 
tures) that win be used as selectkxi critena(i.e.. the Braiid) in a combo box in the right part of the dialog box. Once the 
feature sdection is made, the possa>le values for that feature will appear in a Gst box belcw the selected feature name. 
25 The user may then highlight the features desired. ImmecOately after the feature type O e.. Brand) is selected, a new 
blank feature type selection box appears to the rigM of the selected feature type. This al^^ 

featire choice to use as a selection criteria (i.e.. Subtype). Once again, the possftrfe values are then listed in a list box 

betowthe selected feature type and a third feature type selection combo box appears to the right of the last selection 

coniK) box. This process will repeat until there are no nwe feature types related ^ 
30 all of the choices for the feature by clicking tfie Select * button located directly below the Feature Type dialog box. In the 

Ibltowing example, the resulting domain consists of products in the TROJ' product category with brand being "Fr, "PP" 

or •'S" and subtype being or "S*. The products that satisfy these selection aiteria are shewn in the Troducts" Bst. 
As the user niakes selectiorts from arnorig ttie Feature chokies, the list of p^ 

is updated in the Products list box. The user may select a set of these selected products to use as the domain, or may 
35 choose all of the products selected using the Select button. When the user has the desired s^ 

to copy the selectbn to the EdH Data Domain diatog box. 

Scenark>s78 

40 Sceriarios 78 are the vehk:le for saving arid retoacfirigexperirnernal work. Fi^ 

save a scenark) to retain the wfiat-if analysis work performed. Once a scenario is saved, it may t>e accessed t>y other 
users as a means of sharing analysis and planning results among cfifferent users. A scenario may also be used to save 
the logK behind a business dedskxi, so the factors contributing to the deds^ 
si)ly reused. 

45 When the user Chooses Save Scenario from the Re rnenugrotp, the Save Scenario (fialog box is pr 

figure 54). At the top of tf)e(fiak)gbGK is an ecfitbCK showing the name of the selected scenario tfie current information 
shouM t>e saved to If the user wishes to create a new scenark). the name of the scenarto is tyf>ed into thi^ 
the data will be saved under this new scertarto nania Sceriario narnes rnust be unque^ 

The user has write access to a Scenario 78 to save tfie modified information to an existing scenario. Scenarios 78 

50 for whk*i the user does not have write^)rivneges will appear grayed-out in the Save Scenario dialog box. and the DSS 
10 will not allow the user to save to this scenarto. The user rnay also add a description to the sceri^ descrip- 
tion will appear at the bottom of the Save Scenario screen. This is a free text area where the user may type any words 
to descrbe the scenario. Each time the scenario is saved, the Date Updated fieU of the scenario is automatically 
changed to the current date and time. The scenario is saved wtien the user cficks the OK button. If the i^er clicks the 

55 Cancel button, the scenario is not saved. 

If the i^er w^es to bad an existing Scerario 78 , tfie Open Scenario menu chok;e on the File menu is selected 
(see figure 55). Scenarios 78 that were CTeated by other us«s appear with a RO tag. for read only. These Scenarios 78 
may be loaded but cannot be saved. The iser may always save these Scenarios 78 to a new scenario, if desired. 
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Demand Management Frame 

The User Interface for Demand Management (DM) Frame 130 provides the user with a consistent environment for 
carrying out these five activities: Demand Characterization; BotlonKjp Forecasting; Tofxlcwn Forecasting; Sales Pro- 
5 motion Analysis; and Forecast Performance Evaluation. 

Each of these activities requires a slightly cWferent User Interface to accompfish the task at hand. Therefore, a dif- 
ferent saeen is used for each, although they will share many common elements, tools, and procedures. Within the DM 
Frame, any nun4)er of activities can Inoperative, however, the user ^ one screen at a tim& The user may 

change the view from one saeen to anrther without losing any data a configurati^ 
10 screen. 

All DM activities take place within the same data domain, although different Data Domains may t>e active in other 
Frames 16 of the DSS 10. The user can select a new data domain for the DM activities at any time using the standard 
DSS 10 data domain selection dialog txsx. 

There are several desirable features conrmrion to each of the DM screens. Regardless of the area in which the user 

15 is working, the user is at>le to perform the following operations: save and retrieve DM configuration information; save 
and retrieve data from the DSS Database 12; save and retrieve DM data as a scenario; display pointKrf-sales or ship- 
ment data (where ^icaWe); specify limits on data time series; specify the resolution of data time series (yearly, 
monthly, weekly); display data as absolute values, or as percentages of some total values; display data in tabular or 
grapWcal forni; dear, cut copy, paste data series within the DSS 1 0 and Windows environment; and apply functions to 

20 dataina**scratch'*orworkarea. 

Work Area Pop-tp Saeen 

V 

In additfon to the defeated screens, a pop-up window is available to act as a scratch or worit area. Data series can 
25 be cuL copied, and pasted to and from this window and other DSS windows, as well as other Windows appfications. 
Users can use this window to process and analyze data. 

The following sections descrbe each of the DM screens in more detail. 

Demand Characterization 

30 

This area of the demand characterization screen enables the user to visuaHze the selected domain in outline fomi. 
The user can then select one or rnore data slreains at any level of aggregation, and by using the opti menu, specify 
the type of data to be displayed: sales history, sales characteristkx, or Market Date 140. The Martlet Data 140 may not 
be always available at the same resolutfon as the firm's Demand History Data 136. Therefore, spedal "msakeH Data 
55 Domains'* are aeated to facflitate access to the Mari^ Data 140. 

On the right hand side of the grid the user can choose between a set of summary statistics to be displayed: YTD 
Year to date; YTG Year to go; YTDL >fear to date last year; YTDB \fear to date budget. YTGB Year to go budget; and 
L12M Last 12 months. 

Several analysis tools are avaflabte: Trend. Moving average. Pattern changes, Pareto analysis, and correlation 
40 between products. The output Of these analyses can be displayed in taUe or in graph. 

Sales Characteristics Screen 

A s^ of Sates Characteristics can be computed and displayed in a special table: average level of demand, trend. 
45 volatiBty. and lunr^iness. Accessing this table can be done throi^ 

Bottom-Up Forecast 

The Bottom-Up (BU) forecast screen (see figure 56) contains a Customer Table and a Product Table whk;h have 
so several configuratsle columns and dada display options. BU operations and functions are accessed from the BU screen 
menu and subsequ^cfialog txBces. 

Customer Table 

55 Since BU forecasting is a custonr>erKlriven operation, the topmost t^e displays the customer tree for the selected 
domain. Only those domain entries wftich are strictly customer-orierrted are shown in the customer tabia Entries are 
cfisplayed in an outlir^ form as they were defined in the dwnain. The first column in the tat)le lists the names of customer 
groups or customers, while the remaining columns contain the total sales data for tfiat customer. A split line in the table 
cfivkles historical and Forecast Data 146. The tinrte spans lor historical and Forecast Data 1 46 can be specified the 
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user. 

Customer grotps may be exparxjed or collapsed by ck)d^ theirnamesin the Customer column entry. 

Product Table 

The bottom table displays aD products carried by the selected custor^ Sales data for each product shown 

is presented in outfine fomv which may be expanded or cdlapsed by double clicking on a product name. The entries 
beneath each product include actual orders, forward orders, and orientation orders. As with the Customer Table, the 
table is split to show both historical and Forecast Data 1 46. The user may specify the position in the time series for the 
historical and Forecast Data 146. Promotion periods are highlighted on the (fisplay. 

Total Columns 

On the rigW side of the Product table is three cdumns which can display a select!^ 
following choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB 
Year to go budget; and L12M Last 12 months. 

General Features 

Promotions periods are cfisplayed his^ilighted. The impact of promoted verses unpromoted sales can be cfisplayed 
separately in drop^ cells. The mix percentage can be used to cfisaggregate a forecast generated at the aggregated 
lerel of the customer or cu^omer group. Disaggregation can also be done based on the total for the year and some 
user defined seasonality factors when the menu option Disaggregate Total year" is chosen. Time series of user defined 
leacfing incBcalors" can be cfisplayed for reference and forecasting purposes. 

Tcp-Down Forecast 

As would be expected, the Top-Down CTD) forecast screen (see figure 57) is similar to the Bottom-Up Forecast 
screen, except that the interface is arranged for product-driven forecast operations. On the TD saeen the Product table 
appears at the top^ whBe the Customer table appears below it Data display opti^ 
ations are accessed from the TD screen menu and subsequent dialog boxes. 

ProductTable 

The Product table displays the Bst off products from the selected domain. Only those ertlries which are strictly prod- 
uct-oriented are shown in this table, and are displayed in an outline form as they were defined in the domain. The first 
coturm in the table lists the narnes of product groups or incfividual products, while the rernai columns contain the 
sales data for that product agyegated at the appropriate level. A split line in the table divides historical and Forecast 
Data 146. , 

Then the user selects a product group or product from the Product table, the fist of customers carrying the prod- 
itt;l(s) is displayed in the Customer teble as descrfoed below. Product grou^ 
cficWng their names in the Product column entry. 

CustonDer Table 

The bottom table displays all cuslonriers who carry any off the products selected 
carries all off the selected products, it fe cfisplayed in a focused foni othe^^ 

each customer is shown. The entries beneath each product include actual orders, fonward orders, and orientation 
orders. As with the Product table, the customer table is split to show both historical and Forecast Data 146. The user 
may spedfy the position in the time series for the historical and Forecast Data 1 46. Promotion periods are highlighted 
on ttie (fisptay. 

Total Columns 

On the right side of the Customer table are three columns which can display a selection of user^effined totals from 
the following choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to 

Year to go budget; and L12M Last 12 months. 
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General Features 

Promotion periods are displayed highlig^tted. The innpacl of promoted verses unpromoted sales can be dsplayed 
separately in drcpHJff ceOs. The mix percentage can be used to disaggre^ 

level of the customer or customer groip. Cfeaggre^on can also be done based on the total tor the year and some 
user defined seasonality feictors when the menu option Disaggregate Total Year is chosen. Time series of user defined 
leading indicators" can be (fisplayed for reference and forecasting purposes^ 

Sales Promotion Analysis 

The User Interface that supports Sales Promotion Analysis is built around the promotion calendar. The promotion 
calendar shows the Bst of all the past and planned promotions for the srt of products and customers defined by the 
selected domain. 

For each promotion the Ibflowing is cOspl^ed in the promotion calendar: starting date of the promotion; end date 
of the promotion; promotion type; promotion dass; product being promoted; customers supporting the promotions; pro^ 
nrtotton tntenaty; and impact of the promotion. 

When the user cficks on the promotion calendar button on the toolbar, the promotion calendar Main Display Win- 
dow is displayed (see figure 58). 

The user can select one or several promotions in the promotion calendar. For these promotions the user can per- 
form the operations discussed below. Display shipment and POS Data 1 38 in table fonmats similar to the one used in 
BU and TD forecasts. Conpute the promotion impact for past pnxnotion& Estimate the irrpact of future promotions. 
Display graphically the irnpact of the pronKtioris on sales. 

If the user wishes to view the customer-product tiple (domain) that prorrolions are displayed for, or wishes to limit 
the promotfons shown by choosing what Promotion Type, Promotion Class and Promotion Intensity he wishes to ana- 
lyze, the Promotion Selection Wizard may be invoked. The user selects the customer-product pairs that analysis is to 
tate place on and can liriiit the selection ty choosing what Promotion Ty^ 

he wishes to analyza When the OK button is dicKed. the Promotion Calendar dialog box is populated with all promo- 
tions that match the selection criteria (See figure 59). 

PSI Frame 

The PSI main screen is a work area where the user can experiment with different Production, Inventory and Sales 
f^es and see the Effects caused by these changes to eventually converge to the most desirable PSI plan 190. The 
Main PSI Saeen (see figire 61 ) initially shows the Productioa Inventory and Sales for all of the products in the user 
selected domain. The figures for all of the products are aggraded together and shown. The user may also select any 
incfivkiual product in the aggregatfon and show the numbers for this product alone. This can be done by choosing the 
desired product rttin*)er from the Product setectton combo boK toca^ 

in the corrto box is aN*«ys AD Products to altow the aggregatfon 0^ The user may change the 

products being analyzed by selecting a new set of products from all availdWe products. This may be done by selecting 
a new domain. 

Directly fol towing the Production (P), Inventory (I) and Sales (S) lines are Temporary R S and I fines (see figure 60). 
This is a work area where the user rnay copy and experirnent with the real P, S or I figures and modify them to aeale 
new Scenarios 78. Copy and Paste are enaWed on this fanrn so the user nay copy the ori 
areas. The user may also copy a tirne series from another part of the DSS 10 a a separate app^ 
lines through copy and paste Lastty^theuserrray toad date from a saved scenarfo to the terriporary lines on ft^ 
The incfividual cells that comprise the temporary work area may be manually ecfited by the user by dkidng on the 

desired cell and changing the value in the cell. 

Also presert on the work area of the form are Top-Down, Bottom Upi Custornwdenandink^^ aTop-Down 

minus Bottom Up CTD-BU) and Top-Down ninus Sales (TD-S) lines. These lines give the user different and useful views 

into the pianring data under analysis. These Bnes are calculated based on the values in the temporary P, S and I lines 

of the form. 

The last cdunwi cfisplayed on the saeen is a sum of the data dispfayed on the saeen for the currem year. This crt^ 
umn remains on the screen and does not saoll left to right as other columns are being scrofled horizontally. The titles 
of the vartous horizontal lines of data also does not scroO. but the data series may be scrolled fonward or backward 
through time. The month and year associated with the data are cfisplayed immecfiately above the woridng area of the 
screen. 
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PSI Recondriation 



While vwridna with 1t» date in the tenpofary PJ and S 
.JT^J^^ Thfe mav be acconplished by selecting PSI Reconciliation on the Options menu (see figure 62). 

by the .Sr. PSI Recondlialion 1 70 functions by updating one line of date bas^^^ 
fcU The user has control o««r which line gets ipdated by setting the PSI reconahat^ 

^^.^sSSSpSlreconalialionoJjer by Choosing pa 
61) wfll open the PSI Reconcfliation Dialog Box (see figure 82). From th« w,ndow *e«er ^ 
hSrSw Ofe^dated when the selected 
updated when the Production line is changed. 

Capacity Checking 

While worldng with the Production, biventory and Sales figures, the user nrj^wish to *f 
existing proA^ resources to determine if the currert plan is feasible. TO^ 

S^SSd^cBcking the Check Capacity button on the Options menu gro.^) on the ma.n PSI screen. The main 
caoaatvchecWnacfiatog box will then be displayed (see figure 63). ;^«.««^e,:„„ 
^Sitior^t^Xstheusertoselectthedesiredp^ 
lines that^^^oduce the products with the selected featura The user may remove 
to analyze. The user may select the Producer 

^ m^^lSe^le options before pertorming capacity checking to restrict the scope of the Model Engme 20. and 

^"l^I^^'Ki^SSS^e resute Of the capadty checking. For all producte selected, a p^u^on 
plan dS^^S^TSi top 5 the sieen. whether or not the plan is feasible is indk«ted. The capacrty checking 

monZL fSThas^caicityife.^^^ 

much capacity remains or how much more is needed by kwking at the Owr and Underjine^^ .^^,™woa,i„„ 
^nwtScomponerts t* (see figure 66) is used to view the importent components required to assemble aftnal 

prodI?^<SSSr. usitig the^ent'figures. there is sufficient quantity of ^^^^'^'^'^^^^^ 
S requiring one key component is scheduled and the part win run out then the key component 8 .^^ 

Ml of HAaterial teb (seefigue 67) alkM*s the user to see whfch components are used in which products. By 
selecting specific componente, the user can see which producte use the componente. K»o.*^,toHinr 

Tl^S^STbomSn^^ 
rtherconiwnenteduring production. The user may viewthe Bstintwoways. By selecbn^ 

the user can see specific componente and any alternative parte that eodsl ^ _^ , . ^.^^ 

^Resouro?S3teb(seef«ure69)altows1heusertoseBthepro^^ 

assembly ine and product feature typa The user may view this by setecting a je *^ 

produced on the line or by selecting a product group then a line and viewmg the schedute for the selected 

groups. 

Key Componente Selection 

To analyze productfon of a product the user must work with the componente that are used to bidd ^ 
user does iSiStoSiaustively analyze an corrponente, but justasubsetrt 
SSl^ofCroSS^SreferredtoastheKeyComponen^^^ 
may dtenge over time, so the user must have a way of selecting the currert key componente. 

using the Key Component Selection (iatog box (see f igure 70). ^...^^ 

Ihe K^cSr^^rts column of the main display area indicates whether the <»;:]J»^'tl^ 
key componente are also shown in a list at the rigW of the diatog to. The u^^^ 

oTmultipte conponente by selecting them and clicking the Key Componente button to set them to »^ « NotK^ 
S^Iponentet^ 

the top of the list by cficWng the Sort Componente buttoa _^ ...^ u- 

tSo second Sumn of the main display area is a totel for a selected renge of "^^^l^^^^^Z^^ 
year. The user may select a different range by using the mouse to highlight a range of months and clKi«^ 
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Based on Months button. This will retolal the cdumnforlhe selected range of months and change the caption for the 

colurm to incficate the nfx)nth range selected, rt vwD also sort 

avaOat)ility ever usage to least availabOity over usage ever the selected time period. 

The many features and advantages off the invention are apparent from the detailed specification and, thus, it is 
5 intended by the s^jpenAed claims to cover all such features and advantages of the invention which fall within the true 
spirit and scope of the invention. Further, since numerous modificalions and changes wID readily occur to those sIdDed 
in the art, it is not desired to Emit the invention to the exact construction and operation iflustrated and described, and 
accorcGngty all suit^e mocfif icalions and equivalents may be resorted to, falling within the scope of the invention. 

10 

Appendix A 

Database Specifications for Manufacturing Supply Chain 
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The following are t:he specifications of the data tables for the 
manufacturing supply chain . 



Aggregate Production Plan Data 

Data related to the aggregate production plan for the product and resource 



Field Identifier 


Field 
Type 


Description | 


APPHeaderlD 


Long 


APP Header identifier (see aggregate | 
production plan Header table) 1 


TimePeriod 


Date/Time 


Time period nunber 1 


SupplyOrderZD 


Text 


Supply order pegged to (if . B 
available) H 


1 Quantity 


Double 


Slumber of units of production D 


ProposedChange 


Double 


Recommended change in the planned B 
quantity (to store changes between | 
regeneration of APPs) | 



35 



40 



45 



50 



55 
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Aggregate Production Plan H e ad er 



10 



IS 



20 



25 



30 



Field Identifier 


Field 


Description | 


APPHeaderlD 




AFP Data oerxes i.asuwi£iex^ ■ 


APPID 


Text 


Identifier for an aggregate U 
production plan | 


ResourceResolution 


Text 


ii«karMiT*r*i» B^kfioluticii' R— Resource. 6* 1 
Group, N-Hode | 


Resource ID 


Text 


Resource associated with an 
aggregate production plan 


ProductResolution 


Text 


PZOU.UC& itesoiu.t.i.031 » *^ ^i.w**t*w*- f w 


Product ID 


Text 


•ptj -n-f^itj-it- maar%f^4 M^mA w^th ail aocTrecrate 
production plan 


. TimeResolution 


Text 


D for day; W for week; P for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateCreated 


Date/Time 


Date yiben the aggregate production 
plan was created (based on the time 
resolution) 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


irumber of scenarios in which this 
header participates i 



40 



Budget Data 





Field Type 


Description 1 






Budget header identifier 1 




Date/Time 


Time period number 1 






Target revenue in $ | 


1 BudgetCost 


Double 


Allocated cost in $ 1 



45 



50 



55 
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Budget Header ^ ^ ^ ^ 

Heeler file for defining the Product X Resource X Customer X Time 



10 



15 



20 



25 







Description 1 


1 BudgetHeaderlD 




Identifier for the BudgetHeader B 


1 ProductResolution 


Text 






Text 


1 


CustomerHesolution 


Text 


Customer Resolution: C for Customer, D 
G Cor customer , a kox ox u 


Customer ID 


Text 


Customer associated with the budget 1 


ResourceResolutioQ 


Text 


Resource Resolution: R-Resource, 6- R 
Group, N-Mode | 


Resource ID 


Text 


Resource assocxatea witn tne nuage^ i 


TimeResolution 


Text 


w for week; P for bi-weeiay; M for 
monthly; B for bi -monthly; Q for 
quarterly; and A for annually 


CaTendarlD 




Pegged to a predefined calendar 




Date/Time 


Date of creation for this header 


1 8cenari<^ta 


Bcx3lean 


Yes if it is scenario data. No 


1 ScenarioCounter 


Byte 


IMmber of scenarios in which this 
header participates 



30 



35 



40 



45 



50 







Description 1 




j£a 


unique calendar identifier 1 


Date 


Date/Time 


Julian Calendar Date fl 


DayNo 


Double 


unique number for a day in the y 
cal^Twjl^^" year (typically 1 through 1 
365) D 


HeekNo 


Double 


Unique number for a week in the 1 
year (typically 1 through 52) 




Double 


Unique number for a bi-week in the 
calendar year (typically 1 throuqh 26) 


NanthHo 


Double 


Unqiue number for a month in the 

year (typically l through 12) 


BiMonthHo 


Double 


Unique number for a bi-month in the 
calendar vear (typically 1 through 6) 


Quartei^io 


Double 


unique number for a quarter in the H 
calendar year (typically 1 through 4) 1 


1 Holidaylndicator 


Boolean 


To indicate whether it is a holiday or | 
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Field Identifier 


Field Type 


Description | 


OonponentZD 


Text 


OocnponentlD in the planning BOM from 
corporate master (e.g. 3317307) 


ConponentWunw 


Text 


Nane of the component 


HinPackQuantity 


Double 


H'tnimna pacfc quantity 


Pfaya icalParane t er 


Text 


Physical dimensions for the 
component 


OompCategozy 


Text 


S for Off-the-shelf; C for 
Customized 


Packaginglnstnicticm 


Text 


Special packaging requirements | 



Cooponent Accommodation Katrix 



20 


Field Identifier 


Field Type 


Description | 




Product ID 


Text 


SKD number 1 




PrimaryConqponentlD 


Text 


Primary con^xment identifier H 


25 


AltemativeCoaqponentID 


Text 


Alternative con^ponent identifier U 


30 


Quantity 


Text 


2luster of components ■ of the 1 
Alternative Component that can 1 
substitute for one unit of the || 
Primary component to piroduct 
ProductID B 



Cocyon e nt Requirement Data 

ats for the 



It identified in the header 



Field Idmtif ier 


Field Type 


Description 1 


Coof>Rec^eaderID 


Ijpng 


Identifier for the con^>onent | 
requirement header H 


TimePeriod 


Date /Time 


Time period' number | 


Quantity 


Double 


Number of units during the time period 1 


Proposed Change 


Double 


Proposed Change in required qpiantity | 



45 



50 
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Component Requlranent H e ad e r 

Header £ile defining the Component X Time resolutions and values for 





airement data 


5 


Field Identifier 


Field Type 


Description | 




Comp&e<|BeaderID 


Long 


Component Requirernent Header 1 
Identifier 1 


„ 


Cong)onentID 


Text 


CoRponent associated with an 1 
cocqponents requirements plan | 




BOMZD 


Text 


Unique identifier for BCM 1 




DateCreated 


Date/Time 


Date «dien the component requirements 1 
plan was created (based on the time 1 
resolution) R 


15 


TigaResolution 


Text 


D for day; w for week; P for bi- | 
weeiay; H for monthly; B for bi- 1 
monthly; Q for quarterly; and A for | 

tlHIIMfl * A J ■ 


20 


Calendar ID 


Integer 


Peqqed to a predefined calendar 8 




APPID 


Text 


Pegged to an aggregate production plan B 
(if warranted) 1 




ScenariOData 


Boolean 


Yes if it is scenario data, no 1 
otherwise H 




ScenarioCounter 


Byte 


Number of scenarios in ^^ch this | 
header participates I 


Component Supplier 
Data for the svwliez 


of component 


s 




Field Identifier 








CompSupplierlD 


Text 


unique identifier for the coog>onent | 
siqpplier | 


35 


Sv^XierHazne 


Text 


Name of the component supplier K 




PaymentTems 


Text 


Bxanple : Net- 6 0 




StreetAddress 


Text 


Street Address 




StatelD 


Text 


Name of the State 


40 


PostalCode 


Text 


Postal code 




Country 


Text 


Name of the country 



45 



50 
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ConipGEnent Supply Contract 

Data associated with the coBqpottmt_g\gpplj;_coptract 





Field Type 


Description . H 




Text 


Identifier for the susiply contract 1 


ContzactOate 


Text 


Date of the contract 1 


HomialLeadTime 


Text 


Negotiated nominal lead time for a 1 
defined average c[uantity 1 


Unit Price 




WMvn^4at*M9 uni^t sricfi of the component 1 


^£ W y V o ^wwuu 


Double 


Percentage of discount if the quantity 
is above Qtyf miscount 


QtyforDiscount 


Double 


Minimum size of the Order to qualify 
for the quantity discoimt . 




MinOrderQty 


Double 


Minimum quantity that can be ordered 
from the siqiplier 


CoBnponent Siqpply Mode 




supply node 






Description 


1 CoinpSiqiplyMbdeZD 


Text 


unique identifier for the mipply node 
(e.g., CVTCabinetHodel) 


1 CcapSupplierlD 




TAmn^i €-i»-r e%f ^>t^ i ■tf'wwnonftnt SUDDlier 


1 AvnOimnl vT^adtimc 
■ Avyou^^*^ x ******* 


Double 


Average lead time to stqpply the 
?fnnr57r*Jits (from the time of order) 


1 SupplyOontractID 


Text 


ID for the Simply Contract (See 
Component Supply Contract Table) 


1 Pre£erredCarrier 


Text 


Preferred transportation carrier for 
shipping (e.g.# FBDBX) 


Customer 

Data for individual c 


nistomers 








Description 


CustomerZD 


Text 


rstat-rwnMr ^Tfln enrporate customer 




Text 


Specific customer locatxon ie.3- i^*/ 


DemandBodelD 


Text 


The node this customer is 
associated with 


B CustoroerHame 


Text 


Name of the customer 


1 Address 


Text 


Street address 


State 


Text 


Name of the state 


Postal Code 


Text 


Postal code (Zipcode for domestic) 


Country 


Text 


Nome of the Country 
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Customer Grov^ 
Data for cuatooer groupa 



Field Identifier 


Field Type 


Description O 


CustomerGroupID 


Text 


Identifier for the customer group | 


CustomerGroupKame 


Text 


Descriptive name of customer groi^ 1 
(e.g.. Stereo CTV) R 


CuBtocDexGrou3)Tag 


Text 


Organizational entity ^Ato defined the H 
build criteria for the customer group U 
(e.g. Har)ceting) 1 


Coament 


Text 




SceziarioGroiq> 


Boolean 


yes if this is scenario groi^; No 1 
otherwise 1 


Customer Groiqp Def iziition 

Table that identifies the parent-child relationship between customer groups 
and customers 


iField Identifier 


Field Type 


Description n 


1 CustomerGroupID 


Text 


Name of the customer group H 


1 CustomerlD 


Text 


name of the member customer (or i 
custmer group) J 



30 



35 



40 



45 



50 
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Customer Orders 

Data for actual ciistcroer orxiere 







Field Type 


Description 




5 


CustomerOrderld 


Text 


ID for the actual customer order (e.g. 
pcec type l orders) 






Llnftitemio 


Text 


Line item within the order 






CiiatomerOrderRefHo 


Text 


Customer's purchase order identifier 




10 




T^xt 


Customer identified with the order 






ShlpToIiOCatioa 


Text 


Ship to location for the order 






Product ID 


Text 


Product associated %rith the order 










Pegged to a calendar 




IS 


TiEaeResolutlon 


Text 


D for day; W for week; P for bi- 
weekly; M for montniy; b zor dx- 
monthly; Q for quarterly; and A for 
annually. 




20 


OrderBntryDate 


Date/Tine 


Bscpressed in terms of the calendar and 
time resolution 






RequestedDate 


Date/Time 


Bxpressed in terms of the calendar and 
time resolution 






DueDate 


Date/Time 


Bxpressed in terms of the calendar and 
time resolution 




25 




Date/Time 


Bxpressed in terms of the calendar and 
tine resolution 






DeliveryDate 


Date/Time 


Bxpressed in terms of the calendar and 
time resolution 










Quantity of the order B 


30 


Comnents 


Meoio 


Such as valxie added services 1 
associated with the order I 


35 


Customer Product Reso 
Table that identifies 


lurce Relation 
the Cufltocner 

ts 


ship Hatrix 

Product and Resources that have 








Description 1 




ProductSesoluiion 


Text 


Resolution of the product; P for 
product, G for product group 




40 


Product ID 


Text 


Identifier for the product or product 








Custocnei^tesoluticQ 


Text 


Resolution of the customer: C for 
customer, G for customer group 




45 


CustocoerlD 


Text 


Identifier for the customer or 
customer group 






Datatype ID 


Text 


POS Data, Top Down Forecast, Bottom Up 1 
Forecast 1 




ResourceResolution 


Text 


Resolution of the resource: R for 1 
resource. G for resource group n 


50 


Resource ID 


Text 


Identifier for the resource or V 
resource group 1 



55 
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Demand History Data 

Data for the demand hiatory for the product defined in the header 



Field Identifier 


Field Type 


Description 


DesMD^HistBeacterXD 


Xxsng. 


Identifier for a demand history 


TiaePeriod 


Date /Time 


Time period number 


'DflsnandDfcv 




Demand Quantity 


Demand Biatory Header 
Header file defining 
varioua demand histor 


the Customer : 
Les 


t Product X Time resolutions k values for 


Field Identifier 


Field Type 


Descriptico * 


l>fl***y**j|yigt:HeaderTP 


lioog 


Identifier for a demand history header 


ProductSesolution 


Text 


P for product ; G for Product Group; A 
for all products 


Product n> 


Text 


Product associated with demand history 


CustomerResolution 


Text 


S for customer ship to; C for 
customer; G for customer groiq); M for 

nukvlt^^ ■ & far All msfcciBAVfi 


CustcoerlD 


Text 


Customer associated vith demand 
history 


TiraeResolution 


Text 


D for day; W for week; P f or bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
anmuaiy. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateCreated 


Itate/Time 


Date of creation of the header 


ScenarioOata 


Boolean 


Yes if it is scenario data. No | 
otherwise 1 


ScenarioCounter 


Byte 


Number of scenarios in ndiich this 1 
header participates R 


Demand Bode 

Data associated vith the demand no 


de 


Field Identifier 


Field Type 


Description 


yWnutrMfWfvfat'yn 


Text 


IKaique identifier for the demand node 
(e.g., SBABS or a region) from the 
enterprise point of view 


DemandNodeHame 


Text 


Description of drmwnd node 


Oonnent 


Text 





Demand Orientation Data 

Data associated with the dwiwind orientation for the product identified in 
the header 



Field Identifier 


Field Type 


Description 


OrientationHeaderlD 





Orientation Header Identifier 


TimePeriod 


Date /Time 


Date trtien the order is projected as 
required | 


Quantity 


Double 


Quantity of the orientation | 
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I>emand Orientation Header 

Header file defining the Customer X Product X Time resolutions and values 
for various *^*«mwH orientations 



1 Field Identifier 


Field Type 


Description 




OrientationHeaderlD 




Orientation Header Identifier 


CustonterResolution 


Text 


S for customer ship to; C for 
customer; 6 for customer group; N for 
market; A for all customers | 


CustomerlD 


Text 


Customer identified with the place 1 

ViM^nH Tift mrA^v 1 




ProductResolution 


Text 


P for product; 6 for product group; A 




Product ID 


Text 


Product associated with the 
orientation order 


TimeResolution 


Text 


D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Long 


Pegged to a calendar 


DateCreated 


Date /Time 


Date the header was created 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioOounter 


Byte 


Number of scenarios in i^iich this- 
header participates 




Domain 

User and dfnfll" descr: 


iption for various domains 




Field Identifier 


Field Type 


Description 


1 


DomainlD 


Long 






DomainName 


Text 


The name of the domain 




DomainOwner 


Text 


The owner of the domain 




Domain Definition 
Domain definitions in 


terms of product, customer and resource groups 


Field Identifier 


Field Type 


Description 




DomainlD 


Long 






Productfiesolution 


Text 


P for product; 6 for Product Group; A 
for all products 




Product 


Text 






CustomerResolution 


Text 


C for customer; 6 for customer group; 
M for market; A for all cxistomers 




Customer 


Text 


1 
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10 



Feature Choices 

The various unique values for the different product features -generated on a 





Field Type 


Description 1 


ProductType 


Text 


The type of the Product that these | 
f eatiires belong to 1 






Feature of the Product 1 






Haxne of the Feature possibility || 



15 



20 



Forecast Data ^ ^ 4- 

Data associated with forecasts for the product -customers identified in the 



Field Identifier 


Field Type 


Descriptim \ 




Long 


Pegged to the Forecast Header' Table 




Date/Time 


Time period number 




Double 


Forecast data value 




Double 


Coefficient of variation of forecast 



Header file defining the Customer X Product X Time resolutions ft values for 







Field Type 


Description 1 






\ — 


Forecast Header Identifier 1 


30 


ProductResolution 


Text 


P for Product. G for Product Grovqp, A 
for all Products 






Text 


Product associated with forecast 




CustonerResolution 


Text 


S for Ship-to, C for Customer, G for 
Customer Grovip, A for all Customers 


35 


- 


Text 


Customer associated with forecast 




TimeResolution 


Text 


D for day; W for week; F for bi- 
weeiay; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


40 




Integer 


Pegged to a predefined calendar 




DateCreated 


Date/Time 


Date when the forecast was created 
(based on the tine resolution) 






Text 


B for bottom-up; T for top-down 


45 


ForecastAssuiqptions 


Hesno 


Assxmptions associated with the 
forecast 






T^ 


Author of the forecast 




ScenarioOata 


Boolean 


Yes if it is a scenario data; No 
otherwise 


SO 


ScenarioCounter 


Byte 


number of scenarios in ^diich this 
header participates 
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Freigiit Rate 






Field Identifier 


Field Type 


Description . | 


FreightRateTablelO 


Text 


Freight rate table identifier | 


FreightDescription 


Text 


Description of the rate table 1 


MaxNeight 


Double 


Kaximum weight limit (e.g. truck 1 
capacity) 11 


MaxCute 


Double 


Hav-inn^ volume limit | 


veightCategory 


Text 


e.g. O-lOOlb, 100-5001b, etc. 1 


MiXeageCategory 


Text 


e.g. less than 100 miles, less than D 
500 miles, etc. 1 


MinicsunsGharge 


Double 


MinicBum charge-associated with a trip 


StdCoat 


Double 


e.g. $ per huxulred weight charge for 
LTL and $/mile for TL 


BconoaiyCoBt 


Double 


e.g. for fedex economy rate 


PremiuxnCost 


Double 


e.g. for fedex next day service 


Inventory Data 

Inventory data for items (products 


or components) identified in the header 


Field Identifier 


Field Type 


Description | 


InventoryHeaderlD 


liOaig 


Inventory Data Series Identifier 1 


TitnePeriod 


Date/Time 


Time period nxmber 1 


OnHandlnventory 


Double 


On- band available inventory for 1 
allocation 1 


OnOrderlnventory 


Double 


On-order inventory 


BacOcOrderlixventory 


Double 


Bac)c- ordered inventory 


InTransit 


Double 


In- transit quantity 


Reservedlnventory 


Double 


Reserved inventory on-hand but 
available for allocation only in case B 
of ^aergency i 
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Inventory He ad er 

Header file defining tlie item (Product or Conyonent) X Tine fc and values. 
fo^variguj^^nj^SSEL^S^ 



Field Identifier 


Field Type 


Description 


IscventoryBeaderlD 




Inventory Data Series Identifier 


TTwmw h orvWode TP 


Text 


Identifier for an inventory logical 
warehouse R 


InventoryOontrolID 


Ttext 


Identifier for inventory control 


It^nlD 


f escb 




X teinReBoxubion 




Tt-Mn Pc»noiu^lan - c for CooDonent. P 
for Product / 0 for Product Group and A 
for All 


TimeResolution 


Text 


D for day; W for week; P for bi- 
weekly; M for monthly; B for bi- 
inonthly; Q for quairteriy;. ana a £0£^ 
annually. 




Integer 


Pegged to a predefined calendar 






H^Tiifm^ inrantory level for the item 


MaxInventoryLevel 


Double 


Hay i mum inwintory level for the item 1 




Date/Time 


Date the inventory header %ras created 


1 ScenarioiData 


Boolean 


Yes if it is scenario data, NO 
otherwise 


1 

1 ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates _| 


Inventory Hode 

Data aasocxatea wxtn 


the inventory node 




Field Type 


Description H 


InventoryHodelB 


Text 


Unique identifier for the inventory fl 
node (e.g., ArdenHarehouse2) 1 


Facility ID 


Text 


Physical Facility identifier 1 


inventoryCategory 


Text 


Component or FG-Bnterprise 


InventoryBchelon 


Double 


1 or 2 


InventoryMOdeHamfi 


Text 


Name for the inventory node 


ServiceLevel 


Double 


Service level for the inventory node 


Address 


Text 


Address for the inventory node 


StorageCi^city 


Double 


Physical storage capacity of the 
inventory node (in cubic feet for 
example) ^ 
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Inventory Parameters 

Data for the inventory control parameters 





Field Type 


oescrxpwxan n 


inventoryOontroX ID 


Text 


Identifier for inventory control D 
parameters: Assume inventory 1 
pluming . inventory control I 


^#^^vfl^ A^1rPiic*tOir 


Double 


Safety stock factor R 




Double 


Target service level 


rvx xcyiyp^ 


Text 


Policy type: 8S,Min/Hax,QR»etc. 


MinlnventoryFactor 


Double 


Minimum Inventory factor (e.g., in 
terns of weeks of sales) 


Maxlnventor^actor 


Double 


Maximum inventory factory (e.g.# 

in tierms of weeks- of sales) 9 


MlnOrderQtyPector 


Double 


M-in4nniin order quantity factor 1 


CarryCaiargePactor 


Double 


Carrying cost factor 


OrderCtiargeFactor 


Double 


Ordering cost factor 




Text 


Tnventory classification 


H Replenishment 


Double 


Frequency of replenishment w.r.t. 
the time resolution in the header 



Market Data 

Data for the market defined in the header 







Field Type 


Description 


30 


MarketHeaderlD 


Long 


ID for market header (see Market 
Header table) 






Date/Time 


Time period 


35 


NarketShare 


Double 


Percentage of share held by the 




ConsumerDemand 


Double 


Total demand quantity 




AverageSell ingPrice 


currency 


Average nait Price of the product 


An 


DemandForecast 


Double 


Forecasted demand 



46 
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Market Header 

Header for defining the maricet (Product X Cuatomer resoltttiona) and valuea 



5 



75 



20 



Field Identifier 


Field Type 


Description I 




KarketBeaderZD 


Long 


Identifier for the mai^t header 


MarketDefinitionZD 


Text 


unique identifier for a marlcet (e.g., 
PTV-S) 




NaricetName 


Text 


Market Description (c.g* Projection TV 
in SellincT floor) 


OataScope 


Text 


Suitable tag: Braxid name (e.g., Sony) 
or industry*wide 




Text 


Source of market data (e.g, HIELSBN) 




Text 


D for da v.* w for week: F for bi- 
weekly; H for monthly; B for bi- 
nwynTrif y ; w ^ox^ ^luu. xy « euiu *% &wit 
annually. 


1 CalendarlD 


Integer 


Pegged to a predefined calendar 




1 ProductResolution 


Text 


P-Product, PG'Product Qroup, A- All 
products 




1 ProductID 


Text 


Identifier for the product 




CuatomerResolution 


Text 


C- Customer, CO- Customer Group, A- All 




Customer ID 


Text 


Identifier for the customer 




DateCreated 


Date/Time 


Date the header was created 




ScenarioData 


Boolean 


Yes if it is scenario data; No 1 
otherwise R 


ScenarioCounter 


Byte 


Number of scenarios in which this B 
header participates | 


Katerial Delivery Scfa 
Material Delivery Seta 


ledule Data 
ledule for the 


Component identified in the header 


Field Identifier 


Field Type 


Description 8 


MDSBeaderlD 


Long 


Identifier for the Material Delivery 
S^iedule Header 




DeliveryDate 


Date/Time 


Material Delivery Date 


Quantity 


Double 


Number of units of material delivery | 



45 
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Material Delivery Schedule He a der 

H^B ft^r file defining Che Coo^xmeat X Supplier Z Time resolutions & values 
for various laterial delivery schedules 



70 



20 



25 



Field Identifier 


Field Type 


Description 


KDSBeaderlD 


I«ong 


Identifier fox the Material Delivery 
Schedule Header 


OoBiponentSupplyHDd 
elD 


Text 


Identifier for cooponent supply node 


Sx^plierZD 


Text 


Si9plier associated with a Material 
Delivery Schedule 


TiraeResolution 


Text 


D for day; W for week; F for bi- 
weekly,* M for mooEithly; B for bi- 
monthly; Q fox quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to « predefined calendar 


DateCreated 


Date/Titie 


Date when « Material Delivery Schedule 
was created (based on consistent tine . 
units 1 


ScenarioData 


Boolean 


Tea IX i.t xs ecenarxo oarw» no 
otherwise 


ScenarioGounter 


Byte 


Nunber of scenarios in which this 
hpadfr participates 


Planning BGM 
Imploded BUI of Mate 


rial used for 


Planning 


Field Identifier 


Field Type 


Description 


BOMID 


Text 


Utiique identifier for the planning BGM 
(defined external to the DSS database) 


Ooo^tonentlD 


Text 


unique coafKment identifier 


Product ID 


Text 


SKD number 


Quantity 


Double 


Number of components used in SKX7 



Point of Sale data for the custoiiier- 


products identified in the header 




Field Identifier 


Field Type 


Description 




POSBeaderlD 





POS Header identifier 


40 


TiinePeriod 


Date/Time 


Tiner period number (beginxang of 
the tine period) 




SellTbrough 


Double 


Sale to end user 




Shipments 


Double 


flHipfiynf » f ron *•>*«» customer DC to 
the stores 


46 


Receipts 


Double 


Shipments from the vendor (e.g. 
pcec) to the customer dc 




DCInventoryStatus 


Double 


Onhftnd inventory at the ship to 
location (customer dc) 


50 


Store InventoryStatus 


Double 


Aggregate onhand inventory of stores 1 
served by the customer ship to 1 
location (e.g. dc) | 




StoresOnOrderQty 


Double 


On order quantity from the stores to 1 
the customer dc 1 
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Hewdf^r file defining the Customer X Product X Time resoLutiona & values for 
various POS Data — 



Field Identifier 




Description 


POSHeaderlD 


Long 


Identifier for the Point of Sales 
Header 


CustomerResolution 


Text 


Custoner Resolution: S for Custoooer 
Shipto, C for Customer, G for Customer 
Group, A for all 




Text 


Should be a valid customer grouqp or a 
null set (e.g.. Selling floor) 




Text 


Product Resolution: P for Product, G 
for Product Group, A for all 




Text 


Product associated with the POS Data 


TimeResolution 


Text 


D for day? H for week; P for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Long 


Pegged to a specific calendar 


DateCreated 


Date/Time 


Date the POS Header was created or 
modified 


ScenarioData 


Boolean 


Yes if it is scenario data; Ho 
otherwise 


ScenarioOo^lnter 


Byte 


number of scenarios in t^ch this 
header participates 



Product 

Data for end products 



Field Identifier 


Field Type 


Description 


Product ID 


Text 


SKD from corporate item master (e.g. 

RRiaaow) 




Text 


Heme of the Product 


H 


Text 


Product Category 




Text 


Example: Brand 




Text 


Example: Screen size 


Features 


Text 


Example: Audio: M-Mono, S-Stereo, P- 
Prologic, D-Dolby Prologic 


Feature4 


Text 


Example: Subtype 




Text 


Example: Cabinet type 




Text 


Bxanple: Chassis type 




Text 


Description of the product 


SKDSize 


Double 


Nunber of product xxnits in a SKD 
(e.g.l) 


1 PhysicalDimensions 


Text 


Height X Depth X Width 


\ Height 


Double 


Weight of the SKD I 
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Product Features 

The feature ll«t of the products 



Field Identifier 


Field Type 


Description . 


Fz^ductCateqory 


Text 


Product Category 






Feature Field Runber 


[peatureH^ne 


Text 


Feature Kaune Description | 


Product Groi^ 

Data for product grou 




Field Identifier 


Field Type 


Description 


ProductGroinpID 


Text 


Identifier for tlie product • group 


ProductOroupNttiDe 


Text 


Descriptive nana of product group 
(e.g. 19Stereo) 


ProductOroupTag 


Text 


Organizational entity «dso defined the 
build criteria for the product group 
(e.q. Marketing) 


ScenarioGroup 


Boolean 


Yes if this is scenario groi^; NO 
otherwise 



Product Group Definition 

Table that identifies the parent-child relationship between product groups 
and products 



1 Field Identifier 


Field Type 


Description 


1 ProductGroupParentID 


Text 


Identifier for the product grotip 
that is the parent 


1 ProductGroupChildID 


Text 


Identifier for the product group or 
product that is the child 


Production Accoinraodation Matrix 
Table that identifies alternative pi 
various products 


roduction resources for producing 


Field Identifier 


Field Type 


Description 


Product ID 


Text 


Identifier for the Product 


PrimaryResourcelD 


Text 


Identifier for the Primary Production 
Resource 


AltemativeResource 
ID 


Text 


Identifier for the Alternative 
Production Resource 


Quantity 


Double 


Kumber of units of Alternative 
Resource that can substitute for 
PriiDEury Resource to Product 
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Production Capacity Data 

Production Capacity Data of the production resource 



header 





Field Type 


Description 


ProductionCiqpacity 




ProGUCtxon capacity Heaoer 10 loee 
Production Cv^city Header Table) 




Date/Time 


Timer period nunber H 


H6Shi£ts 


Double 


Huniber ot planned shifts during the 
time period 


LoadingFactor 


Double 


Planned loading rate (e.g. % 
utilization) 


YieldPactor 


Double 


Target yield values 1 




Double 


^rajected downtime | 




Double 


Capacity required 1 




Double 


Capacity available 1 



Production Capacity Header 

Header file defining the Production Resource & Tine resolutions & 
for various Production Capaci^y_Data__^^_^__^^^^^_.,^ 



Field Identifier 


Field Type 


Description 1 


Product capacityBea 


Long 


Production capacity Header ID 1 


Resourceltesolution 


Text 


N for Production Hdde, RO for 0 
Production Group and R for Production | 
Resource 


Resource ZD 


Text 


Resource (Resource, Group or Node) 
associated with an aggregate 
production plan 


Capacitytmit 


Text 


Bxanple, number of production hours, 
shifts, etc. (related to the time 
resolution) 


TimeResolution 


Text 


D for day; W for week; P for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Integer 


Pegged to a predefined calendar 


1 DateCjreated 


Date/Time 


Date i^ien the aggregate production 
plan was created (based on the time 
resolution) 1 


ScenarioData 


Boolean 


Tes if it is scenario data, B6 
otherwise 


ScenarioCounter 


Byte 


number of scenarios in vrtiich this 
header participates | 
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Production Matrix 

Aggregate matrix defining the production rates for Product X Resource 
cocibinationB ^^^^^^^^^^^^^^^^^^^^^ 



1 Field Identifier 


Field Type 


Description 


1 ProductMatrixID 


Text 


Identifier for the production matrix 


1 ResourceResolution 


Text 


Resource resolution identifier 


Resource ID 


Text 


Unique identifier for the production 
resource (e.g., FAIG) 


ProductResolution 


Text 


Product resolution: C for Component* P 
for Product. 6 for Product Group 


1 ProductID 


Text 


Dhiq^ie identifier for input product 
(group) 


YieldRate 


Double 


Actual yield rate for the product on 
the resource 


TimeResolution 


Text 


D for day; W for week; F for bi- 1 
wemkly: M for monthly; B for bi- . 1 
monthly; Q for quarterly; and A for 1 
annually. 1 




1 ProcessTime 


Double 


Actual time of production 1 


H secupwa urxx i u 




Trf«>n^ifiAir foif h>i<fc setixD time matrix B 


Production Node 

Data for the product! 


on node 




1 Field Identifier 


Field Type 


Description | 


1 ProductionNodelD 


Text 


Xftiique identifier for the production I 
node (e.g., PTVNodel) 1 


1 ProductionliodeMame 


Text 


Name of the production node l 


n CoBRient 


Text 





35 

Production Requir&nents Data 

Production RequiremMits Data for the product identified in the^eader_^ 



1 Field Identifier 


Field Type 


1 

Description H 




ProdReqHeaderIp 


Lo»g 


Production Requirement Header 
identifier (see Production 
Requirements Data Header table) 




TimePeriod 


Date/Time 


Time period number 




Quantity 


Double 


Ifunber of units of production 


45 


Pr^osedChange 


Double 


Proposed change with respect to the 
quantity 



50 
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Production Requiremuits Header 

Header file dfflnlpj the Product X Time resolutions fc values for varxous 



10 



IS 



20 



25 



Field Identifier 


Field Type 


Description 1 


ProdRecfHeaderlD 




Production Requironent Header 1 
Identifier 1 


APPZD 


Text 


Identifier for an aggregate production | 


ProductResolution 


Text 


Product Resolution: P-Prodct, G-Group 


Product ID 


Text 


Product associated with the production 
requirenmts plan 


TimeResolution 


Text 


D for day? W for week; F for bi- 
%feexxy# h ror xBBfoxsLXY » o xv*. 
nionthly; Q for quarterly; and A for 
annually. 






Pegged to a predefined calendar 


1 DateCreated 


Date/Time 


Date yrtt&a the production requirraents 
plan was created (based on the time 
resolution) 


1 ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


1 ScenarioCounter 


Byte 


Kunber of scenarios in idiich this 
header participates 



Data related to past and future promotions for Products & Customers in tne 
header . — 





Field Type 


Description 






Promotion Header Identifier 


TimePeriod 


Date/Time 


Timer period nunber (beginning of the 
time period) 


PromotionDuration 




Time duration for the promotion 


Pre*evaluationQty 


Text 


Bstimate before the promotion for the 1 
sales gty due to the promotion 1 


Post -evaluat ionQty 


Text 


Bstimate after the promotion for the 1 
sales otv due to the promotion | 



45 
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Promotion Header 

Reader file defining the Product X Customer X Time resolutions & values for 
various Promotion data 



2S 



30 



35 



46 



SO 



Field Identifier 


Field Type 


Description | 


PromotionBeadarlD . 


Long 


Identifier for the Promotion Header 0 


CustomerResolution 


Text 


Customer Resolution: S for Customer 1 
Shipto, C for Customer, G for Customer 1 
Group, A for all 1 


Customer ID 


Long 


Should be a valid customer groi^ or a B 
null set (e.g.. Selling floor) 8 


ProductResolution 


Text 


Product Resolution: P for Product, 6 H 
for Product Group, A for all || 


Product ID 


Text 


Product associated with the promotion | 
Data 1 


TimeResolution 


Text 


D for day; W for week; F for bi- || 
weeklv: M for monthlv; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Text 


Pegged to a specific calendar 


ProrootionType 


Text 


R for Retailer; P for PCBC; C for 
CamDAtitoir 


PromotionClass 


Text 


Promotion class (e.g. Price 
Reductions) 


Promotionlntensity 


Double 


Intensity of the promotion (low, B 


ProrootionShapelD 


Long 




I DateCreated 


Date/Time 


Date of creation of the Promotion N 
Header P 


ScenariotData 


Boolean 


1 


oCounter 


Byte 




Resource 

Data related to produ 


LCtion resource 


Field Identifier 


Field Type 


Description 


Resource ID 


Text 


unique identifier for a production 
resource (e.g., FAIG) 


ResourceName 


Text 


Descriptive name 


ResourceGroi^ID 


Text 


Production groi^ this resource belongs 
to 


MaxLineRate 


Double 


Maximum line rate 


NoNorkstations 


Double 


Number of workstations 1 


1 MaxBuf f ers 


Double 


Maximum number of buffers 1 
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Resource Group 

Data related to production resource group 



1 Field Identifier 


Field Type 


Description | 


j ResourceGroupZD 


Text 


ni[d.qae identifier for the production 1 
group (e.g., Plant4) 1 


1 ResourceGroupName 


Text 


Descriptive name 1 


1 ProductionHodelD 


Text 


Production node this grot^ belongs to R 


Attributel 


Text 


Attribute (e.g., Category, Location) fl 


Attrlbute2 


Text 


Attribute (e.g.. Category, Location) R 


Attributes 


Text 


Attribute (e.g.. Category, Location) R 


ScenarioGroiq) 


Boolean 


Yes if this is scenario grotq>; Ko fl 
otherwise __ 1 



Resource Group Definition 

Table that defines the parent-child relationship of the production resource 
group and production resources 



1 Field Identifier 


Field Type 


Description R 


R ResourceGroupParentID 


Text 


Identifier for the resource group | 
that is the parent H 


1 ResourceGroupChildID 


Text 


Identifier for the resource group R 
or product that is the child | 



Sales Requirements Data 

Sales Requirements data for the product identified in the header 



1 Field Identifier 


Field Type 


Description H 


SalesRec^HeaderlD 


Long 


HeaderXD pegged to the Sales - H 
Requir^nent Header table 1 


TimePeriod 


Date /Time 


Time Period pegged to the time 1 
resolution in the Sales requirements 1 
hf^ader table H 


Quantity 


Double 


Quantity required i 
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Sales Requirenents Header 

Headgr file defining the Product X Time resolutions & values for the sales 



5 



IS 



20 



. 25 



30 



35 



40 



45 



\i Field Identifier 


Field Type 


Description 1 


SalesReqHeaderlD 




Header ID of the sales requirements 


ProductResolution 


Text 


Production Resolution: P-Product, 
PO»Product QTOap, AbAll 


1 Product ID 


Text 


Product ID 


j TimeResolution 


Text 


Time Resolution: D-Day, w-WeeUy, M- 
Monthly, Q-Quarterly, Y-Yearly 


I Calendar ID 


Long 


Cnl Pindar ID 


1 OateCreated 


Date/Time 


Date of cireation of the sales 
requirements 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
othervise 


ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates 


Scenario 

Scenario description 


and user info 


rmation 


\ Field Identifier 


Field Type 


Description 1 


Scenario!!) 






ScenarioName 


Text 




TTser 


Text 




Description 


Hemo 




OateCreated 


Date/Time 




DateUpdated 


Date/Time 




Scenario Data Ccmpati 
Table that specifies 
.pocitets on each form 


bility 

«^t data headers can be loaded into each of the data 
for each frame 


Field Identifier 


Field Type 


Description 1 


Frame 


Text 


Frame Hame 


Form 


Integer 


Form Ifunber 


Pocket 


Integer 


Pocket Number 


TableHame 


Text 


Table name for the (Frame, Form, 
Pocket) triple 



so 
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ISr^?e^t^ciS?ains the header ids of the varimis data that exists in 
I^H ^Lr^L^ch form in each frame for different scenarios 



Field Identifier 
ScenarioID 



Field Type 
Long 



Description 




Frame 
Form 



Text 



integer 



Pocket 



Integer 



HeaderlD 



I<ong 



DateCreated 



Pate/Time 



DateUpdated 



Date/Time 



SS^^^trix defining the sequence- dependent setup times for product 





Field Identifier 


Field Type 


Description J 


SetupMatrixIP 


Text 


Identifier for the Setup Matrix 1 


PrevProductID 


Text 


Identifier of the product that has 
:iu8t finished processing 


1 HextProductID 


Text 


Identifier of the product to be set-up 
Gxi the resoxirce 


1 TimeResolution 


Text 


D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for | 
annually. J 




Double 


Actual time to set up 1 



Swply Chain Network ^ ' _ . 

Structural data specifying the siipply chain network 



Field Identifier 



LinkID 



Fiel d Type 
Text 



Description 
Sxapply chain network link identifier 



FrooHodelD 



Text 



A node ID from any of the three node 
classes: component supply, production 
inventory . 



TOSodelD 



Text 



A node ID from any of the three node 
classes; production, invento ry, demand 



■ LinkCapacity 



Double 



Capacity of the link 



TransportLeadTime 



Double 



Transport 
the link 



Lead time associated with 



Distance 



Double 



Transportation distance 



XJjiklndicator 



Boolean 



Yes if it is currently active and in 
use and Ho otherwise 
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Supply Order Data 

Data for the supply orders identified in the he a der 



j Field Identifier 


Field Type 


Description 1 


1 Si^lyOrderHeaderlD 


Long 


Production or Bupply order (e.g. pcec 1 
type 4 orders) 1 


9 OrderOate 


Date/Time 


Date of creation e3q>reased with 1 
respect to calendar 


OrientationDatalD 


Text 


Orientation order associated with 
supply order 




Date /Time 


Date the supply order is due 




Double 


QuAnfcity of the supply order | 



Supply Order Header ^ , ^ 

Header file defining the Product X Customer X Time resolutions & values for 



Field Identifier 


Field Type 


Description 




SupplyOrderHeaderlD 


Long 


Production or. si^ly order (e.g. pcec 
type 4 orders) 




CustomerResolution 


Text 


S for customer ship to; C for 
customer; G for customer group ; M for 
market; A for all customers 




Customer ID 


Text 


Customer identified with the place 
keeping order 




ProductResolution 


Text 


P for product ; 6 for product group; A tt 
for all products H 


Product ID 


Text 


Product associated with the svqpply | 
order R 


TimeSesolut ion 


Text 


D for day; W for week; F for bi- 1 
weekly; M for monthly; B for hi- 1 
monthly; Q for quarterly; and A for | 
annually. 1 


Calendar ID 


Long 


Pegged to a calendar 




DateCreated 


Date /Time 


Date the Supply Order Header was 
created/modified 




ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 




— 

II scenarioCounter 


Byte 


number of scenarios in ^diich this 
header participates 




Temporary Product List 
System table that cont 


rainfl a tempo] 


rary product list 


Field Identifier 


Field Type 


Description 1 


Product ID 


Text 


11 
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VMR Contract 

Data associated with a Vendor Managed Repleniahment Contract 



5 



IS 



20 



Field Identifier 


Field Type 


Description 


VMKOontractZD 


Tex^ 


Identifier for the VMR Contract 


CocitractDate 


Date /Time 


Date of the contract | 


BxpirationDate 


Date/Time 


Bxpiration date of the contract 1 


PaynentTems 


Text 


Bxanple: Net-60, Het-30 


ProductResolut ion 


Text 


FrocniCfc Kesoxucxon: r tor rroaucc* g 
for Product Group, A for all 


Product ID 


Text 


Product associated with the VMR 
contract 


TargetPlllRate 


Double 


Fill rate promised in the VMR 
contract 


TumAroundTime 


Double 


Nominal turnaround time 


NinXnventoryPactor 


Double 


Minimum inventory factor agreed in 
the VMR contract 


MaxInventoryFactor 


Double 


Mayl mnm inventory factor agreed in 
the VMR contract 


OrderRevieiooPactor 


Double 


Customer's rights to revise order 



VMR Data 

Data associated trith Vendor Managed Replenishment for the customers 
identified in the header 





Field Identifier 


Field Type 


Description 




VMRHeaderlD 


Long 


VMR Header Identifier 


30 


OrderDate 


Date/Time 


Date «Aien the VMR order data was 
entered 




PurchaseOrderlD 


Text 


Customer purchase order reference 




Orders tatufi 


Text 


A for allocated; B for badcordered; 


35 


OrderQty 


Double 


Quantity associated with the order 




CumDeliveryQty 


Double 


Quantity delivered against the order 
(cumulative measure) 




DueDate 


Date /Time 


Date idien the order is planned to be 
delivered at the customer site 


40 


DeliveredDate 


Date /Time 


Date trtien the order was actually 
received at the customer site 




ShipOate 


Date/Time 


Date %Aen the order is planned to be 
shipped 


46 


LastShipmentDate 


Date /Time 


Date of the latest shipment - made to 
fulfill an order 




ShipCarrier 


Date/Time 


The carrier used in delivering the 
order (to keep track of the intransit 
inventory) 1 




lankID 


Text 


Pegged to a defined siipply chain linSc 1 
in the supply chain network table 1 


50 


Preig^itRateTablelD 


Text 


Based on transportation mode || 
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VKR Header 

Header file defining the Product X Customer X Time resolutions & vales for 
VMR ' 



1 Field Identifier 


Field Type 


Description 


VMRBeaderXD 




VKR Header Identifier 


CustcmerRe solution 


Text 


Customer Resolution: S for Customer 
Shipto; C for Customer; 6 for Customer 
Qroup, A for all 


CustomerlD 


Text 


Should be a valid customer group or a 1 
mill amt. (e <T. . Sellinci floor) 1 


H prOQUctResoxucxon 




Prwliir^ B^aoltiticn r P for Product . Q 1 
for Product Group, A for all 






9rrt^ae^ cavmrmA fav the VKR contract 


TimeResolution 


Text 


D for day; W for week; F for bi- 

monthly; Q for quarterly; and A for 
annually. 


Calendar ZD 


Integer 


Pegged to a predefined calendar 


Invent oryControl ID 


Text 


Pegged to inventory control parameters 
ID 


VMRContractID 


Text 


Pegged to the VKR Contract table 


DateCreated 


Date/Time 


Date the VHR Header was 
created/modified 


ScenaricData 


Boolean 


Yes if it is scenario data. Ho 
otherwise 


1 ScenarioCounter 


Byte 


Number of scenarios in which this | 
header participates | 
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Appendix B 

Database Specifications for Equipment Repair Supply Chain 
The foUowing are the epecif ications of the data tables for the equipment 
repair supply chain. 



SforStion to classify equipment into groups. This information is 
relevant to identify reliability characteristics of equipment parts. 









Unique identifier for the equipment 




Locatioa of the equipment 


TnffpectinnT/MTff ^1 


Location where the equipment is 

inspsctcd/gaintained ^ 


DateofMfg 


Tear of manufacture of eouipaent 


BunningBoura 


Total CusBilative running hours so far 


Regicn. 


Region of reconnaissance associated with the 1 


Oiaracteristic 
(Identify) 


Other critical characteristic, e.g., total running 1 
time H 


etc. 




Repairable Item and 


Oooponent Information 














MinPackQuantity 


|rtT^4f%tm pacdc quantity 


PhysicalParameter 


PIxysical '•♦"•nnions for the component 




S for Off-the-shelf; C for Customized 


1 Packaginglnatruct 
lion 


Special packaging requirements 


BGM 

Bngineering Bill of 


Material that descrribes Uie product structure from 






BOMID 


ttalqiie identifier for the eafjineering BCM 


ParentType 


Type of the parent: Bouipment/Repair Item/Conponent 


Parentm 


Identifier of the parent (EqoipmentlD or RepairltemID 
or ODogwcgitlD) , 


ChildType 


Type of the c^ld (Repair Item/Coe^onent) 


ChildZD 


Xftiique identifier for the child (RepairltemID or 
CoiBpooentlP) 


1 Quantity 
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Repairable Item 

Characteriatics of repairable Item 



B Field Identifier 


Field Description 


1 RepairltemID 


unique identifier of the repair item 


P RepairltenNaxne 


name/Description of the repair item 


1 PtayBlcalDlmenslona 


Height X Depth X Width | 


1 Weight 


weight of the sxa | 



Component Sx^lier 

Information related to component supplier 



Field Identifier 


Field Description ^ 


CompS^vplierlD 


Unique identifier for the coa^ionent supplier || 


SupplierHame 


Bame of the component supplier 1 


PaymentTerms 


Rxanple: 19et-60 | 


StreetAddress 


Street Address B 


StatelD 


Kame of the State | 


1 PostalCode 


Postal code H 


1 Country 


Heme of the coimtry | 



Supply Information 
Et^air Time Matrix 

Aggregate matrix defining the repair rates for Repair Item X Repair 
Resource combinations 



1 Field Identifier 


Field Description 


1 RepairMatrixID 


Identifier for the repair matrix 


i ResourceResolution 


Resource resolution identifier 


i Resource ID 


Unique identifier for the repair resource 


RepairltemID 


Unique identifier for the repair item 


TimeResolutlon 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


ProcessTime 


Mean time to repair 


SetupMatrixID 


Identifier for the setup time matrix 



45 



50 



55 
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Repair Seti^ Matrix 

Aggregate matrix defining the sequence dependent setup times for r^>air 
item changeovers 



Field Identifier 


Field Description 1 


SetupHatrixZD 


Identifier for the Seti^ Matrix 1 


PrevProduetID 


Identifier of the repair item that has just been . 1 
repaired 1 


HextProductlX) 


Identifier of ^Hf> repair item that needs to be 
repaired 


TioeResolution 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. 


SetupTime 


Actual time to setup 



Repair Capacity Header 

Hgfl d*^ file defining the Repair Resource X Time resolutions L valxies for 



20 



25 



30 



vaiLa-wuo aoj^^baa wnjk^wAb, 

Field Identifier 


Field Description I 


RepairCapacityHeader 


R^>air Capacity Header ID 1 


ResourceResolution 


Resource Group or Resource | 


ResourcelD 


Resource ID 1 


CapacityOnit 


Bxanple, number of production hours, shifts, 1 
etc. (related to the time resolution) 1 


TlmeResolution 


D for day; W for week; F for bi-weekly; M for H 
monthly; B for bi-monthly; Q for quarterly; and | 
A for annually. n 


CaTgndarXD 


Pegged to a predefined cal endar H 


DateCreated 


Date lAien the aggregate repair plan was created | 
(based on the time resolution) | 



39 



40 



45 



50 



1 l^eld Identifier 


Field Description 


RepairCapacityData 
ID 


R^kair Czipacity Data ID. 


TimePeriod 


Time period nunber 


RepairCapaci tyHead 
erID 


Repair Capacity Header ID (See Repair Capacity 
Beader Table) 


HoShifts 


Vuntaex of planned shifts during the time pesriod 


liOadingFactor 


Planned loading rate (e.g. % utilization) 


DowntimeFactor 


Projected downtime 


CapacityRequired 


Capacity required 


CapacityAvailable 


Capacity available 1 



55 
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Repair Bstimatiom Haader 

Header file defining the Item X Time resolutions & values for varxous 



10 



IS 



20 



25 



30 





Field Description 




Repair Estimation Header Identifier 


ARPID 


Identifier for an aggregate repair plan 


1 ItemID 




B TimeResolution 


D for day; W for wee)c; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 




Pegged to a predefined calendar 


1 DateCreated 


Date *dien the Repair Bstiniation plan was created 


R^air Bstination Di 


ita 

ita for the repair item identified in the header 


1 Field Identifier 


Field Description 


1 RepairBatDatalD 


Repair Estimation Data ID 


1 TimePeriod 


Time period nxnober 


1 RepairSstHeaderlD 


Repair Estimation Header Identifier 




Number of units of production 


Q ProposedChange 


Proposed change with respect to the quantity 



Aggregate R^>air Plan He a der 

header file defining the Repair Item X Resource X Time resolutions k values 



35 



40 



4S 



50 



1 Field Identifier 


Field Description 1 


1 RepairPlanHeaderlD 


Repair Pl^ Data Series Identifier 1 




Identifier for an aggregate repair plan 


1 ResourceResolution 


Resource Resolution: R- Resource » 6-6roup, N-Hode 


1 Resource ID 


Resource associated with the repair plan 


1 RepairltesnResolution 


Repair Item Resolution: P-Repair Item, G-Group 




Repair Item associated trith the repair plan 


H TimeResolution 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


1 Calendar ID 


Pegged to a predefined calendar 


1 DateCreated 


Date *rtjen the aggregate production plan was 
created (based on the time resolution) 



55 
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SlinSlSt^'tS^g^te repair plan for the repair item identified in 





Field IdeotiflMgi 
RepairPlannaf TP 


Field Deecriptigo 

Identifier for the Repair Plan Data H 


TimePeriod 


Time period nmnber — — — 


ID 


Repair Plan Head identifier (aee aggregate repair 
plan Header table) — — — 


Q^^^^y 


BuBber of unite to be repairea 


PropoaedChftnge 


■k . - _ -»- J 4 m ^hak nlmned. OUantitV (tO StOre 

RecoBBftCfiofff cnange xn ^nw 


Reader file detinlT 


31 Bgadsr 

tg the Ccn^onent X Time value* for various con^xment 


i Field Identifier 
1 OonpBBtHftwderIP 


Fiexo pescrxpwxon ^^^.^.^^^^^^^^^^^^^^^^j 

Component Estimation Header Identifier 


H VjUliiyUTlPTl W A " 


Coo^onent associated with an component estimation 


1 BOMID 


Oaique identifier for BOM . 


1 DateCreated 


Date «dten the coBBpooent estimation was created (based 
on the time resolution) 


1 TimeResolutioQ 


D for day; W for week; F for bi-wee)ay; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually* 


Calendar ID 


Pegged to a predefined calendar ^ 


RepairPlanID 


Pegged to an aggregate repair plan (if warranted) 



S^^^^S'^^^tB for the co.m,onent identified in the header 



Field Id«itif ler 
CoopBstDatalD 



Ooo^onent Estimation He ader ID (See Component 
Estimation H e ader Table) 



TimePeriod 



Time period number 



ComRecfffeaderlD 



Identifier for the component estimation header 



Quantity 



Mmnber of units dur ing the time period 



Proposed Chang e 



Proposed^^re in required quantity 
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Material Delivery Schedule Header 

Header file definixig the Component X Sillier X Time reeolutiozis k values 
for various material delivery schedules 



5 


Field Identifier 


Field Description H 




NDSBeaderlD 


Identifier for the Material Delivery Schedule B 


10 


OooponentSupplyNOde 
ID 


Identifier for component sv^ly node 0 




Supplier ID 


Supplier associated with a Material Delivery H 
Schedule B 


IS 


TlmeResolution 


D for day? w for week; F for bi-wee)ay; M for | 
monthly; B for bi-monthly; Q for quarterly; and A 1 
for annually. B 




Calendar ID 


Pegged to a predefined calendar 1 




DateCreated 


Date when a Material Delivery Schedule was created 1 
(based on consistent time units) i 



20 



Material Delivery Schedule Data 

Material Delivery Schedule for the Component identified in the header 



Field Identifier 


Field Description 1 


MDSDatalD 


Identifier for Material Delivery Schedule Data 1 




Material Delivery Date 


MDSHeaderlD 


Identifier for the Material Delivery Schedule Header 


Quantity 


Hunter of units of material delivery 



Requircnnents Information 
Requirments History Header 

Header file def iniz^ Equipment X Repair Item X Time resolutions & values 
for various demand histories 



Field Identifier 


Field Description B 


Re<ffli stHeaderlD 


Identifier for a requirements history header B 


Repa i rItenResolution 


P for repair item; 6 for repair it«D Grouqp; A for | 
all r^air items 1 


RepairltemID 


Repair Item associated with requirements history 


BquipmentResolution 


C for Equipment; CG for equipment group; A for 
all equipment 


Equipment ID 


Equipment (Groi:^) associated «rith requirements 
history 


TimeSesolution 


D for day; W for week; F for bi-weeJcly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for azxnually. 


Calendar ID 


Pegged to a predefined calendar | 
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Requirements History Data 

Data for the demand history for the product defined in the header 



1 Field Identifier 


Field Description 


ReiJBistDataZD 


Requirements History Data identifier (see 
Requirements History Header table) . 


TimePeriod 


Time period nuxhber 


Re^HistHeaderlD 


Identifier for a requirements history header 1 


RequirementsQty 


Requirements Quantity I 


Bquipoent Repair Orders 

Data for actual equipment repair orders 


-Pield-Id»tifier- 


-Picld-Dsscripticn 




ID for the actual ec^uipment repair order 


LineltraXD 


Line item within the order 


RepairOrderRefHb 


Repair order identifier 


EquipmentID 


Equipment identified with the order 


fl RepairZtemZD 


Repair Item associated %d.th the order | 


1 Calendar ID 


Pegged to a calendar 1 


TimeResolution 


D for day; W for week; F for bi-weekly; M for 1 
monthly; B for bi-monthly; Q for quarterly; and A for 
axmually. 


OrderEntryDate, 


Ba^ressed in terms of the calendar and time 
resolution 


RequestedDate 


Baqpressed in terms of the calendar and time 
resolution 


DueDate 


Esq^ssed in terms of the calendar and tin» 
resolution 


ShipDate 


Expressed in terms of the calendar and time 1 
resolution | 


DeliveryDate 


Bi^ressed in terms of the calendar and time 
resolution 


Quantity 


Quantity of the order 


Oonnenta 


Such as value added services associated with the 
order 



145 



EP0 770967A2 



Future Requirements Header 

Header file defining the Customer X Product X Time resolutions & vaZties for 
various future requirements 



Field Identifier 


Field Description | 


FutureRe<^pSeaderID 


Future Requirements Header Identifier | 


RenairXtemfiesolution 


P for Repair Itettij G for Repair Item Group r A D 
for all Repair Itras R 




RenaJ^r Item (SrouD) associated with, forecast 




C fair Rauimifiiifc . CQ for eaulTsntfixit. oroiXD ? A for 
all equipment 


Equipment ID 


Equipment (Groiq>) associated with requirements 
history 1 


TimeResolution 


D for day; W for week; F for bi-wsc)tly; M for 
monthly; B for bi-monthly; Q for quarterly; and 
A for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date %Aien the forecast was created (based on the 
time resolution) 


PutReqrype 


B for bottom-up; T for top-down 


BstimationAsaumptions 


AsBun^tions associated with the estimation 


BstimateOimer 


Author of the future requirements 



Future Requirements Data 

Data associated with the future requirements for the equipment -repair it«ns 
identified in the header 



Field Identifier 


Field Description | 


FutureRegPatalD 


Future requirements data series identifier 


TimePeriod 


Time period number 


FutureReqHeaderlD 


Pegged to the Future Requirements Header Table 


BstimateValue 


Future requirements data value 


BstinateCV 


Coefficient of variation of estimate 
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Activity Header 



10 



IS 



20 



25 





Field Description 


1 ActivityHeaderlD 


Identifier for the Activity Header 


BquipmentBesolution 


Bquipment Group Resolution: C for Bqaipment, G 
for Bcuipment 6roiq>, A for all 


TTjiii I i wlWTit'TP 


ID of the ecjuipment associated with the activity 


Itepa.iz'I t einResolut ion 


Repair Item Resolution: P for Repair Item, G for 
Repair Item Group, A for all 


RepairltemID 


Rppflir Item assocxatea wxtn ue autxirity ua\m 


TimeBesoXution 


D for day; W for week; P for bi-weeiay; M for 
naathly; B for bi-nsmthly; Q for quarterly; and A 


CalenrtarlP 


Pegged to a specific calendar 


ActivityType 


CocDpany wide, location level, etc. 


ActivitydMs 


Activity class 


■ Activitylnteasity 


Intensity of the activity (low, medium, high) 


1 ActivityShapelD 


Intensity of the activity (low, medium, high) 



Activity Data 



30 



35 



40 





Field Description 


ActivityPatalD 


Activity Data Series Identifier 


TimePeriod 


Timer period number (beginning of the time period) 


ActivityHeaderlD 


Activity Header Identifier 


1 ActivityDuration 


Time duration for the activity 


1 Pre- 

1 evaluationQty 


Bstiroate before the activity for the quantity due to 
the activity 


1 Post- 

1 evaluationQty 


Estimate after the activity for the quantity due to 
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Inventory I&£ozxnatio& 

SS^fil^^dSinixig the Repair Item X Time reaolutioM values for 











Tnventoi^ Data Series Identifier 




Identifier for an inventory logic warehoiiae 


i InventorvCont rol ID 


Identifier for inventory control parameters 


y itenResolutioxi 


Item Resolution: C for Component, P for Product, 0 





prnviiT* Tten ID 1 


TiiseResolution 


D for day; w for week? F for bi-weekly; M f or 1 
monthiy; B for bi-monthly; Q*^ for quarterly; and A n 


CalenrtarlD 


Pegged to a predefined calendar — 1 


1 MinlnventoryLevel 


Minimum inventory level for the item _l 






Inventory Data 








InventoryDatalD 


Inventory data identifier (see inventory Header 
table) , : . 


TimePeriod 


Time period number _^ 


InventoryHeadftrlD 


Inventory Data Series Identifier 


B OnHandlnventory 


On-hand available inventory for allocation 


OnOrderlixventory 


On-order inventory 


BackOrder Inventory 


Back-ordered inventory ^ ^ 


InTransit 


In- transit quantity 


Reservedlnventory 


fieserved inventory on-hand but available for 
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Inventory Parameters 



10 



IS 



20 



25 



30 



35 



Field Identifier 


Field Description 




Identifier for inventory control parameters: Assume 
imramtory planning* inventory control 


•SafetyStockFactor 


Safety stoclc factor 


B TargetServiceLevel 


Target service level R 


1 PolicyType 


Policy type: 38, Min/Max, OR. etc. 


MinlnventoryFactor 


Minimum inventory factor (e.g.* in terms of weeks 
of sales) 


MaxInventoryFactor 


Mnylmtim inventory factor (e.g.* in terms of weeks 
of sales) 


NinOrderQtyFactor 


Minimum order quantity factor 




Carrying cost factor 




Ordering cost factor 1 




Inventory classification 1 


ReplenisfamentPregu 


Frequency of replenishment w.r.t. the time | 
resolution in the header 1 



Repair Resource Information 

Information related to the repair technician and test equipment 
Repair Resource 

I>ata r elated to repair resource 



Field Identifier 



RepairResIP 



RepairitesNa 
1 RepairRe8Groiq>IP 
I MaxLineRate 
|NoWo]^8tatiG 



Field Description 



nnique identifier for a repair resource (e.g. 



FAIG) 



Descriptive name 



Repair resource group this resource belongs to 



Maximum line rate 



guntoer of workstations 



i 



40 
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50 



Repair Resource Group 



Field Identifier 


Field Description 1 


RapairResGroiq>ID 


nnique identifier for the r^>air resource groiq> 1 
(e.g., Plant4) | 


RepairResQroupWame 


Descriptive name 1 




Repair node this groap belongs to | 


Attributel 


Attribute (e.g.. Category, Location) R 


H Attribute2 


Attribute (e.g.. Category, Location) D 


1 Attribute3 


Attribute (e.g.. Category, Location) 1 
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i^pendix C 

Interim Design Documentation for the System Integrator 
of the Supply Frame Chain Ncinager 

Class name: 

PrameHanager 

Category iSi^yply Fraune Chain Manager 
Documentation : 

This is a singleton class. It is running on the server. 
It has to be started before a client can start and make 
connection to it. The FrameManager is responsible to 
facilitate the integration of the client side of the 
system (the User Interface 18) with the server side of 
the system where the mathematiccQ Model Engines and the 
DSS 10 database reside. The FrameManager is composed of 
a ClientManager, a ServerManager, a collection of 
Request Interpreter and objects which form the Functional 
Integrator 312. When a client program start up, it will 
connect to the FrameManager (obtain the object reference 
of the FrameManager) and call the initialization 
function. As part of the initialization of the client 
with the FrameManager, a Request Interpreter object will 
be created, inserted into the collection and the object 
reference will be retxim back to the client. The client 
will also be registered with the ClientManager object of 
the FrameManager. The initialization also includes the 
user authentication. 
Export Control : Public 
Cardinality: 1 
Hierarchy : 
Superclasses : none 
Associations : 

<no rolename> : ClientManager in association 
<no rolename> : Request Interpreter in 

association 

<no rolename> : ServerManager in association 
Public Interface: 
Operations : 

FrameManager 
initializeClient 

Private Interface: 
Attributes : 

mClientManager : ClientManager 
mServerManager : ServerManager 
mRequestlnterpreter : 

List<RequestInterpreter> 

A linked list of 
Request Interpreter. Each Requestlnterpreter will run in a 
separate thread or a separate process. This way, requests from 
multiple clients can be handled concurrently. 

State machine: No 

Concurrency : Sequential 

Persistence : Transient 

Operation name: 
FrameManager 

Public member of : FrameManager 

Arguments : 

char* f rameMgrConf igFi le 
Documentation : 

This is the constructor is the FrameManager. At the 
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it will read in the coiif iguration 

construction txoe, (•frameMgrConfigPile-) . The 

SSiS (tSstSlS^on which machines) , how many number of 

^Halizl all other data member of thxs class. 
Concxunrency : Sequent ial 

Operation name; 

initializeClient 
Ptiblic mwnber of iFraroeManager 
Return Class: Request Interpreter^ 
Arguments : 

char*\iseri9ame 
chau:*hostName 
char*pasaword 
HotifyMsg&nbtifyMsg 

°*^^f ^'client program has started ^^obtained the 
^>^^or'^ ireference of the FrameManager, it wxll call tnis 
^ScScTtl'^ti^ itself with the Franker. ^ will 

?T ;j?n Sr^eTf^^ihSScS ^ reStering 
^S'TS^ SiSiiSQ^ Th^ object reference of a «>tify!teg on 
^i"** i?S^^rM88 in. This object reference will be 

This function will return the object reference of a 
Re«nestInteSreter through which the client will make all its 

requests. 

Concurrency :Sequentiai 

Class name: 

ClientManager 
Category: Supply Frame Chain Manager 

^^^'^^^^i"^ monitor the client connection^ Implement 

IE iS?rtf Se^trtSI^^ll?o^^^ 

sE3sn^ ^ -o^trs^^c^cS^ rs sit, . 

Export Control: Public 
Cardinality:! 
Hierarchy: 
Superclasses : none 

Associations^ rolename> : FrameManager in association 
Public Interface: 
Operatxons . registerClient 
mai t ainCl lent 

Private Interface: 

Attributes : . . ^ 

clients : List<Client> 

A linked list of Client. The 
Client class contain the basic information about the* client, 
such as? the user name, the. client host name, the 
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corresponding Reques t Interpreter , t ime of ' init ial connect ion , 
time of last request, pending requests, etc. 

State machine: No 

Concurrency : Sequent ial 

Persistence : Transient 

Operation name: 

regis terCl ient 

Public member of : ClientManager 

Return Class :bool 

Arguments : 

Client&aClient 
Documentation : 

Add a client to the client list. Enforce the relevant 
FrameManager policy such as the maximum • number of simultaneous 
client . 

Concurrency : Sequential 
Operation name: 

maitainClient 
Public member of : ClientManager 
Documentation: 

This function will be called periodically from the 
FrameManager. Within the function, each client will be 
checked to see if it needs to be disconnected. If a client 
needs to be disconnected, it will be removed from the list and 
the corresponding Request Interpreter object will be deleted. 
Concurrency : Sequential 
Class name: 

Request Interpreter 
Category: Supply Frame Chain Manager 
Documentation : 

This is the object the client is normally interact 
with. Each object of this type has to rvn in its own thread or 
process so that multiple client can request server services 
concurrently - 

Export Control : Public 
Cardinality : n 
Hierarchy : 

Superclasses : none 
Associations : 

<no rolename> : FrameManager in association 
Public Interface: 
Operations: 

request 

Private Interface: 
Attributes : 
theClient : Client* 

Reference to the client with whom this 
Interpreter is associated. 
State machine: No 
Concurrency : Sequential 
Persistence : Tremsient 
Operation name: 
request 

Public member of : Request Interpreter 

Return Class :bool 

Arguments: 

longscenar io ID 
longdomainID 
longrequest ID 
boolasynch 
long&resul t ID 
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Documentation : 

This function will be called by the client to make a 
request to perfonn certain task by the server (s) 1 The 
scenarioID and domainID will identify the data associated with 
the request. The request ID will identify what kind of action 
need to be performed (by looking up a table within the 
system). If the request is not asynchronous ("asynch" false") 
the result will be returned immediately through the value of 
result ID. The client can retrieve the actual data from the 
DSS Database through the resultID in the table associated with 
that type of request. If the request of aynchronous, the 

result will be sent to the client later by calling the 
NotifyMsg object of the client. 

Concurrency : Sequential 

Class name: 

ServerManager 

Category : Stqpply Frame Chain Manager 

Documentation: 

Manage the server connection. A server is a program 
(an object) from which we can request specific service. For 
example, we may have a server being able to compute the 
optimal delivery frequency given the maximum inventory and 
service level constrain in a VMR setting. This is referred as 
Model Engine Server. A Model Engine Server can run on the 
same machine where the FrameManager is running, or it can rxin 
on different machine. Two Model Engine Servers of the same 
type can run on the same machine, or they can run on different 
machines. The information governing the policy is stored in 
the FrameManager configuration file, which was read in at the 
time of constructing the FrameManager. The ServerManager will 
enforce the policy such as on which machine to start which 
server, load balancing, etc. The ServerManager is also 
responsible to shutdown the servers when they are not needed. 

Export Control: Public 

Cardinality:! 

Hierarchy: 

Superclasses : none 

Associations : 

<no rolename> : FrameManager in association 

Public Interface: 

Operations : 

addServer 

roaintainServer 

getServer 

Private Interface: 
Attributes : 

servers : List<Server> 

A linked list of Server 
object. A Server is a class %rtxich record the basic information 
about a server, such as name, type, which host it is rtmning 
on, statxis, etc. 

State machine: No 
Concurrency : Sequential 
Persistence : Transient 
Operation name: 
addServer 
Public member of : ServerManager 
Return Class :bool 
Arguments : 

char*aServer 
Documentation: 
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Try to -start a new server of certain type and add it 
to the server list. Here some of the server management policy 
will be enforced. For exsunple, we may have a policy says that 
there should be no more than x number of Lineau: Programming 
servers in the entire system. Or we may have another policy 
says that we can not put more than x number of servers (of all 
types) on machine A. When the function is called only the name 
(type) of the server is passed in. Which machine the server 
should be on is determined within this function. 

Concurrency : Sequent ial 

Operation name: 

maintainServer 

Public member of : ServerManager 

Documentation: 

This function is periodically called from 
FrarceManager . It will check each server to see if any one 
needs to be shutdown. 

Concurrency : Sequential 

Operation name: 
getServer 

Public member of : ServerManager 

Return Class :Server& 

Arguments : 

char*aServer 
Documentation : 

Return a server of the specified type. It first 
check the server list to see if any one of that type is idle. 
If it is, it retiim the reference to that one and update the 
status. If not, it will call the addServer function to try to 
add one. 

Concurrency : Sequential 



Claiins 

1. A decision support system, conrprising: 

decision support frames providing a view into a supply chain; 

a model engine comprising modeOng processes analyzing the chain; and 

a frame manager managing the execution of the modefing processes to provide information for said frames. 

2. A system as recited in daiml. further corrprising a daA^t>asemanagernem system si^^ 
to the modefing processes and said frame manager. 

3- A system as recited in daim 1 , wher^ said system comprises a server mode inducfing said engine and said man- 
ager and a cGent mode comprising said frames. 

4. A system as recited in daim 1, wherein said datet)aseconrprises an invert 
a demand data space. 

5. A system as recited in daim 2, wheran said database includes a supply chain n 
ply node, a pnxftiction node, an inventory node and a demand node. 

6. A system as recited in daim 1 , wheran said modefing processes comprise a componert procurmert policy devel- 
opmert module, a f inished goods distritxition network design module, an aggregate production planning module, a 
finished goods inventory managemert module, a sales forecasting and planning module, a market data analysis 
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module and a vendor managed replentshment mod Je. 
7. A system recited in daim 1 . wherein said manager comprises a system inteyator and a functional integrator, 
a. Asystem as recited in daim 1. wherein the supply chain includes sales, inventory and production. 

9. A decision sMpport system, comprsing: 

decision support frames integrating analytical models of a supply chain responsive to a view point of a busi- 
ness process. 

1 0. A sy^em as recited in daim 9, wherein said frames comprise a supply management frame, a demand manage- 
ment frame, a vendor managed replenishment frame, a planning, sales and inventory frame and a distribution net- 
workframa 

11. A system as recited in daim 10. further comprising a domain management process Dmiting data available to saa 
frames responsive to a user selection. 

1 2. A system as recited In daim 9. further comprising a scenario management process providing scenarios for com- 
parison of management plans. 

13- A decision support system, comprising: 

a demand and supply recondtialion process recondling productiw) 

14- A system as recited in daim 13. wherein said process detenrtnes a feasftMlity capacity plan responsive to supply 
constraints. 

15. A system as recited in daim 13, wherein said process provides a vendor replenishment plan responsive to pre- 
dicted sales and supply constraints. 

16. A system as recited in daim 15, wherein the plan considers production capacity, inventory and point-of-sale infor- 
mation. 

17. A system as recited in daim 15. wherein the plan provides a strategic analysis using quantative models. 

18. A system as recited in daim 13. v^ierein said process reconcfles a tD(Hto^ 

19. A system as recited in daim 18, wherein said bottom-up torecast includes an ex^ 

20. A storage media, conprising a reconcfliation process reconciling production, sales and inventory of a supply chain. 

21. A decision support system, comprising: 

acGentcorrprising: 

decision support frames providing a view into production, sales and inventory of a siw»y chain, said 
frames integrating analytical models of a ajpply chain responsive to a view point of a business process, 
said frames conprising a supply management frame, a demand nranagement frame, a vendor managed 
replenishment frame, a planning, sales and inventory frame and a dslribution networt^ frame; and 

a server comprising: 

a model engine, connprising: 

modeling processes analyzing the chain, said modeling processes comprising a corrponent procure- 
ment policy development module, a finished goods distribution networit design mod Je. an aggregate 
production planning moAile. a finished goods inventory management module, a sales forecasting and 
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planning module, a marked data analysis module and a vendor managed replenishment module; and 

a demand and supply reconciliation process recondOng production, sales and inventory by recondling 

a top^Jowm forecast with a boltomnip forecast including an ex^ 

a capacity process determirang feastoility of a capacity plan responsive to suppty constraints; 

a replenishment process providing a venda replenishment plan responsive to predicted sales and 

supply constrairits said process recondles a topKlowm forecast with a bott^ 

a scenario management process presiding scenarios for comparison of management plans; 

a frame manager managing the execution of the modeling processes to provide information for said 

frames, said manager comprising a system integrator and a functional integrator; 

a database management system supplying database infomnation to the modeling processes and said 

frame manager; and 

a domain manageniert process limiting data avaBable to said franies responsive 
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DSS System Architecture m the Context ofMam^iacturmg Supply Omim 

FIG. 1 
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DSS System Ardtitechtre in the Context cf Equipment Repair Sttpply Chains 



FIG. 2 
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The Data Spaces in Supply Chain Management 

FIG. 3 
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FIG. 4 



160 



EP0770967A2 



in 




161 



EP0770967A2 



o 

z 




i 






1 








> — c 


a. 
3 


3 




ff 


Req 






1 




!ader| 








c 


) — c 


itory 








1 




1 



•a 
o 
Z 

I- 



o 
2 

"a. 

I- 



o 

I- 

o 
U 



c 

s. 

6 
o 
O 



6 




Repair Item 
Group 


Repaii 


) c 



X 



a 

CO 

D 



H 

o 
St 



g 

c 
o 

i- 



162 



EP0770 967A2 



73 



li 



User DM^^-— -]^User Di»phy ^ 



Usetlntet&Ke 



7? 



Scenarios 



Decision 
Siq>port 
76 Frame 



Process Flow 



Decision Logic 
Data Flow Scmario Mgt 



I 



— j Supply Chain FrMoe Manager (Qimt) 



Supply OiMi 
Pie rfb oaance 



I Supply Chain Ftame Manager (Server) 

' J_ 



s«pp>rc 



AO 









Model Engine 



DSS 




Spec^wttion (f Decision Support Frame 



FIG. 7 



163 



EP0770967A2 




BO 



Infimnation Flow ► MatenalFIow I Incision Prtcess 



Decision Processes in the Mmi^acturing Supply Chain 



FIG. 8 



164 



EP0770967 A2 




m^UvdlAoddtfmEqmpnentBepatSupplyOum 

FIG. 9 



165 



EP0770 967 A2 




166 



EP0770967A2 





Modules 


Associated 
Data Spaces 


Sales Forecasting & Plannmg 


O 


Market Data Analysis 





Data Space Assodatums of the Demand Mamgpment Frame 

FIG. 1 1 



EP0770 967A2 




Customer 



Process Flow cf the Demand Management Frame 

FIG. 1 2 



168 



EP0 770967 A2 




AOO 



SUPPLY 
ORDER DATA 



15/ 



BadcH3Tders& 
Expedites 



(36 



1 



DEMAND 
HISrORY 
DATA 



I^pdate (fistory 



I 

Actual 

Demand 



150 



V] CUSTOMER 
ORDERS 




INVENTORY 
DATA 



r 



Ihventory 
Status Inventory 
Update 




Order Order 
Enquiry ConfinnaticHi 



Order^ Entry 



Customer 



Process Flaw cf Order Fu^ment 



FIG. 13 



169 



EP 0 770 967 A2 



PRC^OnON 
. DATA ^ 



P06 DATA 



T 



138 



140 



MARKET 
DATA 



Demand Management 




Sales Plan 



FORECAST 

DATA: 
Botfc(Kn-Up& 
Top-Down^ 



1 



DEMAND 
ORIENTATION 
DATA _x 



I4K 



160 



Z 



CUSTOMER 
ORDERS 



Dtemand Management 




154 



Customer-Demand 
History 



/3fc 



DEMAND 
HISTOKY 
DATA 



Dflia Flowfor the Demand h4amgement Frame 



FIG. 1 4 



170 



EP0770 967A2 



V 


Modules 


Associated 
Data Spaces 


Sales Forecasting & Planning 




Aggregate Production Planning 


V 


Finished Goods Inventory Management 





Data Space Associations of the Production-SaleS'Inventory Planning Frame 

FIG. 15 



EP0770967A2 



^6. 



FORK^STDATA: 

Bottook-Up 




INVENTORY DATA: 
Reftuirements 



170 



FGIM 

— 3f — 



PSI 

RecondliatLon 



INVE NTORY 
PARAMETERS 



V 

I73t. 




APP 


>. 




< 1 



ISO 



REQUIREMENTS 
DATA 



PRODUCTION 
CAPACITY 
DATA 



r 



INVENTORY DATA: 
Coi np o n c nt 
AvailabiUly 



INVENTORY 
DATA: 
Status 




Process Flaw of the Production'SaleS'Inventory Planning Frame 



FIG. 1 6 



172 



EP0 770967 A2 



CWEMAND 
HISTORY 
DATA 



INVENTORY DATA: 
Status 



INVENTORY DATA: 
Co mp onent 
AvaUabiHty 



PRODUCTION 
CAPACmf 
DATA 



X 



m 



PSman 



INVENTORY 
PARAMETERS 




FORECAST DATA: 
Bottom-Up & 
Top-DowTi 



INVENTORY DATA: 
Requirements 



PRODUCTION 
REQUIREMENTS 
DATA 



Data Flow for the Proiuction-Sales-lTwentory Planning Frame 



FIG. 17 



173 



EP0770967A2 



V 


Modules 


Associated 
Data Spaces 


Component Procurement Policy 
Development 




Aggregate Production Planning 


V 


Finished Goods Inventory Management 





Data Space Associations cfthe Supply Management Frame 

FIG. 18 



EP0 770 967 A2 



INVENTORY 
DATA: Status 




PRODUCnON 
CAPAOTY 
DATA: Long-term 



CX^IPONENT 
REQUIREMENT 
DATA: Long^tom 



3i3SL 



FGIM 

— r~ 



0 



APP 



PRODucncm 

REQUIREN4ENT5 
DATA 



174 




PRODUCTION 
CAPACITY 
DATA 



AGGREGATE 
PRODUCnON 
PLAN DATA 



l?0 



PRODUCnON 
MATRIX 



2 



UL 



1 



CPPD 



COB 

SUPPLY 
^^CONTRACr 

a34 



hit 

iff 

I' 







^teTERlSL 


PLANNING 




DELIVERY 


BOM 




SCHEDULE 




V^DATA ^ 





INVENTORYDATA: 

AvailabiKty^^ 



\2X 



Process Flaw of the Supply Management Frame 



FIG. 19 



175 



EP077D967A2 



INVENTORY 
DATA: Status 



MAIERIAL 
DELIVERY 
SCHEDULE DATA 



;74 



SUPPLY 
■ CONTRACT 



PRODUCTION 
NfATRDC 



Master 
Production 
Plan 




PRODUCTION 
CAPACITY DATA: 
Long-tcnn 



COMPONENT 
REQUIREMENT 
DATA: Long-tEnn 



A 

500 





PRODUCTION 
CAPACITY DATA 

AGGREGATE 
PRODUCTION 
PLAN DATA 



Data Flow for the Supply Mamgment Frame 

FIG. 20 



176 



EP0770967A2 




PRODUCnCWJ 
CAPAOTYD^nA 

^ A " ^ 
¥_ 



Sttpply 
Management 




AGGREGATE 
PRODUCTION 
PLAN DATA 



I 
I 



Ftoductioii 
Capacity Ran 



Data Flaw far the Supply Management Frame 



FIG. 21 



177 



EP0770967A2 





Modules 


Associated 
Data Spaces 


Market Data Analysis 




Sales Forecasting & Planning 


o 


Finished Goods Inventory 
Management 




Vendor Managed Replenishment 





Data Space Associations ofihe Vendor Managed Replenishment Frame 

FIG. 22 



EP0770967A2 



FOSDATA 




VMR 

Strategic 
Planning 



RnanrialA Business ■ 



Customer 



MDA 



FGIM 



13a. i ^134 isa. 



J-1 



SF&P i 



INVENTOBYDATA: 
Replenishment 
Requirements 



VMROC»nRACT: 
Policy & Target 



: SUPPLY CHAIN 
NETWORK: 
Transportation 
Factors 



t 



010 

>: 



Replenishment 
Planning 



i 



VMRUAIAT 
Replenishment 
Sd\edule 




\ 

JL 



^ FORECAST 

: DATA: 
J Bottom-up 





Supply 
Management 



Process flaw of the Vendor Managed Replenishment Frame 



FIG. 23 



179 



EP0770967A2 



! SUPPLYOIAIN 
I NETWORK: 

Factocs 




Data Flawfmr ihe Vendor Managed Replenishment Frame 



FIG. 24 



180 



EP0770967A2 



V 


Modules 


Associated 
Data Spaces 


Madcet Data Analj/Bis 




Sales Forecasting & Planning 




Finished Goods Inventory 
Management 


© 


Finished Goods Distribution 
Network Design 


V 



Data Space Associations cffhe Distribution Network Design Frame 

FIG. 25 



181 



EP0770967AZ 




iili 
if ■ 



MDA 



SF&F 



FORECAST 
DATA: 



PRODUCTION 

CAPACITY i 
^ DATA > 

t 



! I 



FGDND 



16) 



"<i 

i 

i. 




Hp 



FGIM 



INVB^RY 
NODE 



SUPPLY CHAIN 
NETWORK: Link 
Inclination i 



INVENTORY : 
HEADER: Product I 
Asgigprosnt 



I INVENTORY j 
Ig ARAMET^ ; 



Process Flow (fthe Distribution Nehoork Design Frame 



FIG. 26 



182 



EP0770 967A2 



J 







C ^ 






PRODUCTION 


FREIGHT RATE 




CAPACmf 


^ 







FORECAST 
DATA: Aggregate 
. Forecasts > 



INVENTORY 
PARAMETERS 



INVENTORY 
HEADER: Product 
^^^^^^^^Assignmeitt 



T 



Distribution 
Network 
Desie;n 



300 j Customer-DC 
Asagnment 



m 



SUPPLYCHAIN 
NETWORK: link 
Infpnnation 



DEMAND NODE 



FRODUCnC»J 
NODE 



DOVENTORY 
NODE 




Data Flow far tiie Distribution Network Design Frame 



FIG. 27 



183 



EP0 770 967A2 



v30 



-4 CompOQcnt Procurement 
~j Policy Development 



n 



I Aggregate Pn>ducti<m 

I P lanning 



Finished Goods Distribution \y 
Netwoik Desigo | 

I i' 13a. • 

f T ) 



I Finisbed Goods 
Inventory Mgt 



Sates Forecasting 
aiMl Planning 



InfonnatiGn 
Material 



L 



MadcetData 
Analysis 



Vendor-managed 
Replenisbment 



customers 



component 
&ctoiy 



finished-goods 
fectoiy 




Seven Modules and Supply Cham Management 



FIG. 28 



184 



EP077D967A2 




Pareb) Analysis for ABC Class^kation 



FIG. 29 



185 



EP0770 967A2 



VUatffity 


i 










D 


▲ 

E 

▲ 


F 






C 


▲ 

B 
A 


A 












Sales 



Scatter Plot for Sales-Volatility Class^tion 

FIG. 30 



186 



EP0770967A2 



0 12 3 4 5 



Impact of Sales Promotion 



FIG.31 



187 



EP0770967A2 




Curve Fitting far Promotion Effict Andy sis 

FIG. 32 



188 



EP0770967A2 




System hevd Services, the Seven Modules and Model Engine Utilities 

FIG. 33 



189 



EP0770 967A2 




Supply Chain Frame Manager: High Level Architecture 



FIG. 34 



190 



EP0770 967A2 




Higji Level Ardutecture of the System Integrator 



FIG. 35 



191 



EP0770967A2 



hasa- 



FrameManager 



-mGlientManager : OientManager j 

mServerManager : ServerManager 

-mRequestlnterpreter : UsKRequestlnterpreteP^ has a 



+FrameManager( ) 
•KinitializeClienU ) 



ClientManager 



clients : ljsl<aient> 



registerClient( ) 
maitainClient( ) 



Requestlnterpreter 



theClient : Client* ! 



ServerManager 



servers : List<Server>; 



addSen^er( ) 
maintainServer( ) 
getSen^er( ) 



High level object representation of the system integrator portion of the frame manager 



FIG. 36 



192 



EP0770967A2 



DSS Frame Dedsioos 
fiom systems integrator 



SM 

PSI 
VMR 

DM 



Invntoiy Policy 
SS,O.MinM« 



p fine and vantkm 
I line tnd variation 



TugctLcvd 
Ddivoy Frequency 



Forecast 
Forecast Enors 



330 



350 Netwodc Simulator 



SUPPLIER 



SUPPLY CHANNEL 



Conyoficnt Req 



T 



RECONCILIATION 

1 — T 

Actual S' fine ▼ 
DEMAND CHANNEL I 



CUSTOMER 



Network Configurator 



Scenario Manager 



Domain Manager 



] 



User Access and Privileges 



Output Measures 



Performance Matrices 
for 

all nodes 
all channels 
all echelons 

Si^ly Responsiveness 
FiU Rates 
FG Inventory 
Component Invoitory 
cycle Hme 
Cost 



Level Architecture of tiie Fiinctioiial Integrator 



FIG. 37 



193 



EP0770 967A2 



NODE 



SuppHer Info 
Supplier Plant 

Cosnponets 



PRODUCTION NODE 



ProductInfo 
Manufacturer Plant 

Production Matrix 
Manufacturer Warehouse 




Date fUm diagram for the Sttpply Cham Network Configuratar 



FIG. 38 



194 



EP0770 967A2 



View available domains 

- Display defafult domains and 
user-defined domains. 



DOMAIN 
DATA TABLES 



View the contents of the selected domain 

- Sdect an €9dstii^ domain. 

- Di^lay the tuples within ttie domain. 



Edit osCTKlefined domains 

- Display dimension of dais in a tree vist^ 
Usplay existing domains^ 



Load selected 



Create new 1 
domains 


tsei^defined 


Editodstiiig 
user-defined domaint 









Add tuples 

- Select desired data from 
three dimensions of data 
lists. 

- Disable irrelevant data in 
the ottier data lists based on 
the current selection 

- link and add tiie selection 
to ttte user-defined domain. 



— 1 



Delete tuples 
-Select a tuple to 
delete. 

- Ddete the selected 
tuple 



Ddefte existing 

user-defined 

domains 

-Select a domain to 



-Delete the selected 
dcnnain. 



Save domains 




- Update domain tables 


► 



DOMAIN 
DATA TABLES 



Functwrudity in the Domain Managsr 



FIG. 39 



195 



EP077D967A2 




HienaxMcd Stntcture of a Scemrio 

FIG. 40 



196 



EP0770 967 A2 



DaaT«b>o 



Generate Dtnmd 

sndlodtuse 
fifom (fisriboticns 



Brnkt/Fit 
DistributiGfis 



Histocy/Foxccisi 
i 



GonfiguntDr 




SIMULATION 
ENGINE 



Define PBrftBSuncc 



SccnBiioTest 




ReycMiuig 






■ t 


( 



luvcntoiy Poltcy 



HI 




Systein Imegntor 



Analyttcsl Decision Models 



DSS 



Data How E>iag;ram for tfie Performance Simulator 

FIG. 41 



197 



EP0770 967A2 




198 



EP0770967A2 




199 



EP0770967A2 




200 



EP0770 967 A2 



Windows 3.U 

3^4 









VISUAL BASIC 




374, 




VISUAL C+* 



windows NT 



37? 
\1 



15 



374,-, T 



ACCESS Engine 



ODBC 



S^^ Sgivst 



Supply Ch^ Information Systems 
(IBM SQUDS. UNIX ORACLE, etc) 



1? 



IntBffscB 



Business 
Logic 

350 



Data 

Iteratgement 



DSS Development Pla^inm Emnronment 



FIG. 45 



201 



EP0770 967A2 




^OD the Road 



Generic System Architecture 



FIG. 46 



202 



EP0770967A2 



S 




System Role: 

* OLE Client 
Functional Role 

* Basic System 
Logic 

* Scenario Manager 

* Local DB 



Telephone 
Network 






System Role: 

* OLE Server 

* SNA Server 
^ * SQL Server 

Fimctional Role: 

* Model Engine 
*DSS DB 

* Scenario Data 



DB2 or Other 
applications on 
*IBM 3270 
*5250 
★AS/400 
Or, UNIX 
workstation 



System Architecture 



FIG. 47 



203 



EP0770 967A2 




The Logon Dialog Box 



FIG. 48 



204 



EP0770 967A2 



Agile DSS - [Global Supply Chain View] 




The Opening Screen of the DSS 



FIG. 49 



205 



EP0770967A2 




User Presences Selection Dialog Box 



FIG. 50 



206 



EP0 770 967 A2 




The Select Data Domain Form 

FIG. 51 



207 



EP0770967A2 




208 



EP0770 967A2 




Make Product Domain Dialog Box 

FIG. 53 



209 



EP0770967A2 




Save Scenario Dialog Box 

FIG. 54 



210 



EP0 770 967 A2 




Open Scermrio Dialog Box 

FIG. 55 



211 



EP0770967A2 




Demand Management, Bottom Up Forecast Screen 



FIG. 56 



212 



EP077D967 A2 



£De Edit View Display Tools Options Help 



i . .8l4^i 




Demand Management, Top Down Forecast Screen 



FIG. 57 



213 



EP0770 967A2 




Promotion Calendar Main Display 

FIG. 58 



214 



EP0770967A2 




°n SaeenSize 

+ Q Stcfco 
Mono 

T=| 13P220C 



dJ 19PRaO 
19PRD2 
[=1 25TRD0 
r=l 20R200C 



^ ^ AflCurtom«» 

Top & Bottom Customers 
+ CH Bottom Cittlonws 
~ Top Cu»tome« 

[=1 Best Products 
^ Custcmere by Regno 




iCombol " : ^^ ^JCbrrfco2 [^|^Coinbo3 j|l 



The Promotion Selection Wizard 



FIG. 59 



215 



EP0770967A2 




The Main PSI Frame Form 

FIG. 60 



216 



EP0770967A2 




Sales Planning 
lljAnProS I Inventory Planning 

fe^^gj^ Check Capacity 



PS I Reconciliation Order 
PSI Reconciliation 



CustemerV- 



■:Custofiisw;3-::^t^7j 



>1L ^5768a 1342608 :443475 
ffl9^"4~54l3i_ 362898 -41 6439 
267663 '241861 il9S023 110879 jl64709 0__ .o' 
2928a'7 310935 ;312007"j923fo 255>49' 335635 344577 '339815 
283126 •369750^432037' 270374 361960 35^90" 3^ 959 36604 8 
'enjldaft^ 291795 '372720 :36629b "1263009 389069 377763 35^1 03" :41 8070 



289126 369750 432037 270374 361960 
289126 369760 432037 270374 351960 



-351969 -356048 



The Options menu choices on the PSI screen 

FIG. 61 



217 



EP0 770 967 A2 




PSI Reconciliation Order Dialog Box 

FIG. 62 



218 



EP0770 967A2 




The main capacity checking dialog box - The Options tab 

FIG. 63 



219 



EP0 770967 A2 




The Restdts tab 



FIG. 64 



220 



EP0770 967 A2 




EP0770967A2 




The Key Components tab 

FIG. 66 



EP0770967A2 




The Bill of Material tab 

FIG. 67 



223 



EP0770967A2 




The Alternative Components Tab 

FIG. 68 



224 



EP0770967A2 




The Resource Requirement tab 

FIG. 69 



225 



EP0770 967 A2 




Key Component Selection Dialog Box 



FIG. 70 



226 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the apphcant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

If 

□ IMAGE CUT OFF AT TOF, BOTTOM OR SIDES 
Q FADED TEXT OR DRAWING 



□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 
Q GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMIT! ED ARE POOR QUALITY 

□ OTHER: _^ 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLURRED OR ILLEGIBLE TEXT OR DRAWING 



